diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml index 675a1b1ef4..6a7b555d85 100644 --- a/base_classes/NXlens_em.nxdl.xml +++ b/base_classes/NXlens_em.nxdl.xml @@ -24,7 +24,7 @@ - + Base class for an electro-magnetic lens or a compound lens. @@ -35,40 +35,32 @@ with other research fields (MPES, XPS, OPT) could be useful--> 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. + Descriptor for the lens excitation when the exact technical details + are unknown or not directly controllable as the control software of + the microscope does not enable or was not configured to display these + values (for end users). + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens + setting, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. - - - - + - Ideally an identifier, persistent link, or free text which - gives further details about the lens. + Descriptor for the operation mode of the lens when other details are not + directly controllable as the control software of the microscope + does not enable or is not configured to display these values. + + Like value, the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. + Excitation voltage of the lens. @@ -82,48 +74,20 @@ with other research fields (MPES, XPS, OPT) could be useful--> Excitation current of the lens. For dipoles it is a single number. - For higher order multipoles, 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 - or was not configured to display these values (for end users). - - In this case this value field should be used and the value - from the control software stored as is. - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens setting, - provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. + For higher-order multipoles, it is an array. - + + - This field should be used when the exact operation mode of the lens - is not directly controllable as the control software of the microscope - does not enable or was not configured to display these values. - - Like value the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + - - - 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/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b2909088..84a36254c2 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ + + + Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `JEOL Electron Microscopy Glossary <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. + + + + + Was the corrector used? + + + + + Descriptor for the correction strength along the first direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + + + + + Descriptor for the correction strength along the second direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + + + + + + diff --git a/contributed_definitions/NXcorrector_cc.nxdl.xml b/contributed_definitions/NXcorrector_cc.nxdl.xml new file mode 100644 index 0000000000..e105a6006f --- /dev/null +++ b/contributed_definitions/NXcorrector_cc.nxdl.xml @@ -0,0 +1,51 @@ + + + + + + Base class for corrector reducing chromatic aberrations in an electron microscope. + + Examples are Wien or Omega filter. + + + + + Was the corrector used? + + + + + Qualitative type of the corrector. + + + + + + + + + + + + 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..472d88f33b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml @@ -0,0 +1,872 @@ +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 research data management systems + like NOMAD Oasis. +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 +type: group +NXapm_composition_space_results(NXobject): + + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + definition(NX_CHAR): + \@version: + type: NX_CHAR + 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', 'unbounded'] + program(NX_CHAR): + \@version: + type: NX_CHAR + job_pyiron_identifier(NX_CHAR): + exists: recommended + doc: | + TBD, maybe how to link between pyiron state tracking and app state tracking. + description(NX_CHAR): + 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 + config(NXserialized): + doc: | + The path and name of the config file that was used for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + reconstruction(NXserialized): + doc: | + Details about the file (technology partner or community format) + from which reconstructed ion positions were loaded. + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + ranging(NXserialized): + doc: | + Details about the file (technology partner or community format) + from which ranging definitions were loaded which detail how to + map mass-to-charge-state ratios on iontypes. + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + + # results + results_path(NX_CHAR): + 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 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(NX_CHAR): + exists: recommended + affiliation(NX_CHAR): + exists: optional + (NXidentifier): + exists: optional + role(NX_CHAR): + exists: optional + (NXcoordinate_system_set): + doc: | + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * composition_space + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + (NXcoordinate_system): + (NXtransformations): + + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library + 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 + + # default behaviour, if no coordinate system defined, unclear + # if one coordinate system is defined the origin is defined in this cs + origin(NX_NUMBER): + 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): + unit: NX_UNITLESS + doc: | + + position(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of each cell in Euclidean space. + 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): + unit: NX_UNITLESS + doc: | + For each ion, the identifier of the voxel in which the ion is located. + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXion): + exists: ['min', '0', 'max', 'unbounded'] + 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): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: [[1, n_clst_dict]] + + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + unit: NX_UNITLESS + 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. + 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): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: [[1, n_spat_dict]] + + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + unit: NX_UNITLESS + 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. + 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', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + 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', 'unbounded'] + 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 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0c29376ce1705f690d1267a0cbe4f35e05d3f307951e01669ca735b5b822dccc +# +# +# +# +# +# +# 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 research data management systems +# like NOMAD Oasis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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 that was used for this analysis. +# TBD, this can be e.g. Alaukik's YAML file for composition space. +# +# +# +# +# +# +# +# +# Details about the file (technology partner or community format) +# from which reconstructed ion positions were loaded. +# +# +# +# +# +# +# +# +# Details about the file (technology partner or community format) +# from which ranging definitions were loaded which detail how to +# map mass-to-charge-state ratios on iontypes. +# +# +# +# +# +# +# +# +# +# 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 coordinate systems (reference frames) used. In atom probe several coordinate +# systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` +# should be documented explicitly and doing so by picking from the +# following controlled set of names: +# +# * composition_space +# * lab +# * specimen +# * laser +# * instrument +# * detector +# * recon +# +# The aim of this convention is to support users with contextualizing which reference +# frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` +# are used to detail the explicit affine transformations whereby one can convert +# representations between different reference frames. +# Inspect :ref:`NXtransformations` for further details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml index 78870cc26b..f1e20fe529 100644 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -3,35 +3,28 @@ doc: | Base class for components used in an electron microscope. The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. -# `point Electronic GmbH `_ type: group NXcomponent_em(NXobject): + \@depends_on(NX_CHAR): + doc: | + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. name(NX_CHAR): doc: | - Given name to the component e.g stage, lens C1, etc. - description(NX_CHAR): # NXidentifier + Given name to the component. + + Exemplar value stage, lens C1. + fabrication(NXfabrication): + identifier(NXidentifier): + description(NX_CHAR): doc: | - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - (NXfabrication): + Ideally, use identifier to point to a resource which provides + further details of the component. + + If such a resource does not exist or should not be used, + use this, though discouraged, free-text field to report + further details about the component. (NXprogram): (NXtransformations): doc: | diff --git a/contributed_definitions/nyaml/NXcorrector_ax.yaml b/contributed_definitions/nyaml/NXcorrector_ax.yaml new file mode 100644 index 0000000000..a1b1c9ad2b --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_ax.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 `_ + * `JEOL Electron Microscopy Glossary `_ + + Stigmator is an exact synonym. +type: group +NXcorrector_ax(NXcomponent_em): + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + value_x(NX_NUMBER): + doc: | + Descriptor for the correction strength along the first direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + unit: NX_ANY + value_y(NX_NUMBER): + doc: | + Descriptor for the correction strength along the second direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + # control level perspective + # strength(NX_NUMBER): + # axial component(NX_NUMBER): + # technical design perspective + (NXlens_em): + # (NXaperture_em): + # (NXdeflector): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcorrector_cc.yaml b/contributed_definitions/nyaml/NXcorrector_cc.yaml new file mode 100644 index 0000000000..063eecec3a --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_cc.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class for corrector reducing chromatic aberrations in an electron microscope. + + Examples are Wien or Omega filter. +type: group +NXcorrector_cc(NXcomponent_em): + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + type(NX_CHAR): + doc: | + Qualitative type of the corrector. + enumeration: [wien_filter, omega_filter] + # control level perspective + # technical components of the corrector + (NXlens_em): + (NXaperture_em): + (NXdeflector): + (NXcrystal):