From 64dc03020f8a12455614999d5c75fb2e96bafe60 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Mar 2025 14:10:16 +0100 Subject: [PATCH 01/57] Fine-tuning of the naming conventions for identifier which is now a reserved NeXus keyword versus renaming many of these to index_offset, indices_* --- contributed_definitions/NXapm.nxdl.xml | 32 ++-- .../NXapm_compositionspace_config.nxdl.xml | 4 +- .../NXapm_compositionspace_results.nxdl.xml | 6 +- .../NXapm_reconstruction.nxdl.xml | 2 +- contributed_definitions/NXatom.nxdl.xml | 5 +- .../NXcg_face_list_data_structure.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 10 +- .../NXcg_primitive.nxdl.xml | 12 +- contributed_definitions/NXem.nxdl.xml | 25 +-- .../NXem_calorimetry.nxdl.xml | 19 +-- .../NXevent_data_apm.nxdl.xml | 30 ++-- contributed_definitions/NXimage.nxdl.xml | 20 +-- .../NXinstrument_apm.nxdl.xml | 20 +-- contributed_definitions/NXion.nxdl.xml | 6 +- ...ctro_chemo_mechanical_preparation.nxdl.xml | 59 +++---- .../NXmicrostructure.nxdl.xml | 80 ++++++--- .../NXmicrostructure_gragles_config.nxdl.xml | 2 +- .../NXmicrostructure_gragles_results.nxdl.xml | 19 ++- .../NXmicrostructure_imm_results.nxdl.xml | 6 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 8 +- .../NXmicrostructure_score_config.nxdl.xml | 5 +- .../NXmicrostructure_score_results.nxdl.xml | 24 +-- contributed_definitions/NXphase.nxdl.xml | 33 +++- .../NXsimilarity_grouping.nxdl.xml | 14 +- contributed_definitions/NXspectrum.nxdl.xml | 14 +- contributed_definitions/nyaml/NXapm.yaml | 66 ++++---- .../nyaml/NXapm_compositionspace_config.yaml | 10 +- .../nyaml/NXapm_compositionspace_results.yaml | 14 +- .../nyaml/NXapm_reconstruction.yaml | 6 +- contributed_definitions/nyaml/NXatom.yaml | 12 +- .../nyaml/NXcg_face_list_data_structure.yaml | 30 ++-- .../nyaml/NXcg_half_edge_data_structure.yaml | 22 ++- .../nyaml/NXcg_primitive.yaml | 26 +-- contributed_definitions/nyaml/NXem.yaml | 53 +++--- .../nyaml/NXem_calorimetry.yaml | 38 ++--- .../nyaml/NXevent_data_apm.yaml | 62 +++---- contributed_definitions/nyaml/NXimage.yaml | 42 ++--- .../nyaml/NXinstrument_apm.yaml | 42 ++--- contributed_definitions/nyaml/NXion.yaml | 14 +- ..._electro_chemo_mechanical_preparation.yaml | 123 +++++++------- .../nyaml/NXmicrostructure.yaml | 160 ++++++++++++------ .../NXmicrostructure_gragles_config.yaml | 6 +- .../NXmicrostructure_gragles_results.yaml | 39 +++-- .../nyaml/NXmicrostructure_imm_results.yaml | 14 +- .../NXmicrostructure_kanapy_results.yaml | 18 +- .../nyaml/NXmicrostructure_score_config.yaml | 12 +- .../nyaml/NXmicrostructure_score_results.yaml | 50 +++--- contributed_definitions/nyaml/NXphase.yaml | 58 +++++-- .../nyaml/NXsimilarity_grouping.yaml | 30 ++-- contributed_definitions/nyaml/NXspectrum.yaml | 30 ++-- 50 files changed, 791 insertions(+), 655 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 719cef449b..3ae7f4dba9 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -60,8 +60,8 @@ Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. These ions get new identifier assigned in the process (the so-called - identifier_evaporation). This identifier must not be confused with - the identifier_pulse. Typically smaller than both p_out and p_out. + evaporation_id). This identifier must not be confused with + the pulse_id. Typically smaller than both p_out and p_out. @@ -103,7 +103,7 @@ - + @@ -584,7 +584,7 @@ the application definition here is nothing else then the documentation of this f Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. - That is identifier_evaporation values take the role of an implicit time and course of the experiment given that + That is evaporation_id values take the role of an implicit time and course of the experiment given that ion extraction physically is a sequential process. There is a number of research groups who build own instruments and share different aspects of their technical @@ -707,7 +707,7 @@ details can be useful to convey details about an atom probe instrument in genera As set and measured quantities typically change over time and we do not yet know during the measurement which of the events have associated (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the identifier_evaporation but as a + document quantities as a function of the evaporation_id but as a function of the (pulsing) identifier_event. @@ -719,8 +719,8 @@ but for M-TAP and Oxcart these pieces of information are available.--> +pulse_id_offset(NX_INT): +pulse_id(NX_INT):--> @@ -945,7 +945,7 @@ we can only make recommendations--> CRunHeader.fTotalEventRecords - + Identifier used for each hit_quality type. Following the order of hit_quality_types. @@ -957,7 +957,7 @@ we can only make recommendations--> Hit quality identifier for each pulse. - Identifier have to be within identifier_hit_quality. + Identifier have to be within hit_quality. @@ -982,7 +982,7 @@ insight into the results of the hit_finding algorithm of IVAS/APSuite but typica used only in the context to learn about the multiplicity of an ion. pulses_since_last_ion(NX_UINT): dim: (n,) -identifier_pulse(NX_INT): +pulse_id(NX_INT): dim: (n,) at this point the original set of events p has been filtered down to p_out--> @@ -998,25 +998,25 @@ at this point the original set of events p has been filtered down to p_out--> - + Integer used to name the first pulse to know if there is an - offset of the identifier_evaporation to zero. + offset of the evaporation_id to zero. Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + evaporation_id_offset and cardinality. For example if identifier run from + -2 to 3 the value for evaporation_id_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. + identifier conventions where evaporation_id_offset is 1 and 0 respectively. - + (Molecular) ion identifier which resolves the sequence in which the ions were evaporated but taking into account that a hit_finding diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index f6a7ce115c..750b2ffc69 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -51,7 +51,7 @@ to use for this analysis. - + @@ -75,7 +75,7 @@ iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 9f57f36c81..960f1a2acf 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -150,7 +150,7 @@ for if desired all the dependencies and libraries--> - + Position of each cell in Euclidean space. @@ -170,7 +170,7 @@ for if desired all the dependencies and libraries--> - + For each ion, the identifier of the voxel into which the ion binned. @@ -220,7 +220,7 @@ for if desired all the dependencies and libraries--> - + Element identifier stored sorted in descending order of feature importance. diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml index 95ef358785..8c3348ef37 100644 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -31,7 +31,7 @@ Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. These ions get new identifier assigned in the process - the so-called - identifier_evaporation, which must not be confused with the identifier_pulse! + evaporation_id, which must not be confused with the pulse_id! diff --git a/contributed_definitions/NXatom.nxdl.xml b/contributed_definitions/NXatom.nxdl.xml index bdfca4aa77..8045cd121f 100644 --- a/contributed_definitions/NXatom.nxdl.xml +++ b/contributed_definitions/NXatom.nxdl.xml @@ -79,9 +79,10 @@ - + - Identifier for each atom at locations as detailed by position. + Index for each atom at locations as detailed by position. + Indices can be used as identifier and thus names for individual atoms. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 1ac61c139f..ccebfc8c05 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -68,6 +68,8 @@ duplicate of an NXoff_geometry ?--> Having an own base class for the data structure how primitives are stored is useful to embrace both users with small or detailed specification demands. + + Indices can be used as identifier and thus names for individual instances. @@ -97,7 +99,7 @@ duplicate of an NXoff_geometry ?--> Number of faces of the primitives. - + Integer offset whereby the identifier of the first member of the vertices differs from zero. @@ -106,7 +108,7 @@ duplicate of an NXoff_geometry ?--> Inspect the definition of NXcg_primitive for further details. - + Integer offset whereby the identifier of the first member of the edges differs from zero. @@ -115,7 +117,7 @@ duplicate of an NXoff_geometry ?--> Inspect the definition of NXcg_primitive for further details. - + Integer offset whereby the identifier of the first member of the faces differs from zero. @@ -124,7 +126,7 @@ duplicate of an NXoff_geometry ?--> Inspect the definition of NXcg_primitive for further details. - + Integer identifier to distinguish all vertices explicitly. @@ -132,7 +134,7 @@ duplicate of an NXoff_geometry ?--> - + Integer used to distinguish all edges explicitly. @@ -140,7 +142,7 @@ duplicate of an NXoff_geometry ?--> - + Integer used to distinguish all faces explicitly. diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index c88df09f51..cf36b73d98 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -54,6 +54,8 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. The data structure is also known as a doubly connected edge list. + + Indices can be used as identifier and thus names for individual instances. @@ -83,7 +85,7 @@ - + Integer offset whereby the identifier of the first member of the vertices differs from zero. @@ -92,7 +94,7 @@ Inspect the definition of :ref:`NXcg_primitive` for further details. - + Integer offset whereby the identifier of the first member of the edges differs from zero. @@ -101,7 +103,7 @@ Inspect the definition of :ref:`NXcg_primitive` for further details. - + Integer offset whereby the identifier of the first member of the faces differs from zero. @@ -110,7 +112,7 @@ Inspect the definition of :ref:`NXcg_primitive` for further details. - + The position of the vertices. diff --git a/contributed_definitions/NXcg_primitive.nxdl.xml b/contributed_definitions/NXcg_primitive.nxdl.xml index 4f5da5f2ae..796353f17f 100644 --- a/contributed_definitions/NXcg_primitive.nxdl.xml +++ b/contributed_definitions/NXcg_primitive.nxdl.xml @@ -65,25 +65,27 @@ The cardinality of the primitive set. Value should be equal to c. - + Integer offset whereby the identifier of the first member of the set differs from zero. + Indices can be used as identifiers and thus names of instances. + Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + index_offset and cardinality. For example if identifier run from + -2 to 3 the value for index_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. + identifier conventions where index_offset is 1 and 0 respectively. - + Identifier of each member for explicit indexing. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index a780c45f31..3990428105 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -74,6 +74,7 @@ but for practical purposes currently is interpretable only by human to provide t + Alias (short name) which scientists can use to refer to this experiment. @@ -919,7 +920,7 @@ which components that microscope was built from--> - + @@ -1010,10 +1011,10 @@ which components that microscope was built from--> - + - + @@ -1037,10 +1038,10 @@ which components that microscope was built from--> - + - + @@ -1067,10 +1068,10 @@ which components that microscope was built from--> - + - + @@ -1097,7 +1098,7 @@ which components that microscope was built from--> - + @@ -1173,7 +1174,7 @@ which components that microscope was built from--> - + @@ -1188,7 +1189,7 @@ which components that microscope was built from--> - + @@ -1206,7 +1207,7 @@ which components that microscope was built from--> - + @@ -1227,7 +1228,7 @@ which components that microscope was built from--> - + diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index 1e762e1687..6756ad8df0 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -66,6 +66,7 @@ are aligned with what and how to name things--> + Details about performance, profiling, etc. @@ -94,14 +95,11 @@ are aligned with what and how to name things--> - + - A qualifier whether the sample is a real one or a virtual one. + Qualifier whether the sample is a real (in which case is_simulation should be set to false) + or a virtual one (in which case is_simulation should be set to true). - - - - @@ -112,8 +110,7 @@ are aligned with what and how to name things--> The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by identifier_parent or walk through - eventually deeply nested groups in data instances. + these from the resources. @@ -167,7 +164,7 @@ are aligned with what and how to name things--> delta_time. - + @@ -193,7 +190,7 @@ Timestamp that is used for each diffraction pattern to correlate the results obtained from that pattern with associated actuator data. ISO8601 with local time zone information if possible and as precise as practically possible. The indices follow the same order as -used for identifier_pattern. +used for indices_pattern. dim: (n_p,)--> @@ -261,7 +258,7 @@ NXcg_ellipsoid--> - + Identifier for each pattern. diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 80b0f7daf6..39fac4b100 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -41,7 +41,7 @@ of atom probe research. Against static and dynamic quantities are split to avoid a duplication of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the identifier_pulse field. The point in time when each was issued + These pulses are identified via the pulse_id field. The point in time when each was issued is specified via the combination of start_time and delta_time. Conceptually and technically NeXus currently stores tensorial information as arrays of values @@ -64,10 +64,10 @@ However, there is no independent logical connection between these two concepts, i.e. temperature and time_stamp. - In the case of atom probe though the time that one would use in NXlog is defined implicitly via identifier_pulse, + In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_id, which is the independent variable vector against which eventually dozens of channels of data are logged. Not only are these channels logged they should ideally also be self-descriptive in that these channels have - identifier_pulse as the independent variable but we do not wish to duplicate this information all the time but + pulse_id as the independent variable but we do not wish to duplicate this information all the time but reference it. Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the @@ -95,18 +95,18 @@ - Delta time array which resolves for each identifier_pulse the time difference + Delta time array which resolves for each pulse_id the time difference between when that pulse was issued and start_time. - In summary, using start_time, end_time, delta_time, identifier_pulse_offset, - and identifier_pulse exactly specifies the connection between when a pulse was + In summary, using start_time, end_time, delta_time, pulse_id_offset, + and pulse_id exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + Integer used to name the first pulse to know if there is an offset of the identifiers to zero. @@ -116,20 +116,20 @@ :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + pulse_id_offset and cardinality. For example if identifier run from + -2 to 3 the value for pulse_id_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. + identifier conventions where pulse_id_offset is 1 and 0 respectively. - + Identifier that contextualizes how the detector and pulser of an atom probe instrument follows a sequence of pulses to trigger field evaporation. - The identifier_pulse is used to associate thus an information about time + The pulse_id is used to associate thus an information about time when quantities have been collected via sampling. In virtually all cases the pulser is a blackbox. Depending on how the @@ -138,17 +138,17 @@ Maybe the first part of the experiment is run at a certain pulse fraction but thereafter the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, identifier_pulse is then an equally + collects all measured values of the pulse_fraction, pulse_id is then an equally long vector which stores the set of events (e.g. pulsing events) when that value was measured. This may cause several situations: In the case that e.g. the pulse_fraction is never changed and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the identifier_pulse e.g. 0 to indicate that the pulse_fraction was set + and a single value for the pulse_id e.g. 0 to indicate that the pulse_fraction was set at the beginning and it was maintained constant during the measurement. If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of identifier_pulse are then [0, 99999] respectively. + pulse onwards. The values of pulse_id are then [0, 99999] respectively. diff --git a/contributed_definitions/NXimage.nxdl.xml b/contributed_definitions/NXimage.nxdl.xml index 9bafb0b584..e44f7f2941 100644 --- a/contributed_definitions/NXimage.nxdl.xml +++ b/contributed_definitions/NXimage.nxdl.xml @@ -82,10 +82,10 @@ It is often the case that several images are combined using processing. In this case, the number of images which are combined into collections is not necessarily the same for each collection. The NXimage base class addresses this logical distinction - through the notation of identifier_image and identifier_group concepts. - That is identifier_image are always counting from offset in increments of one. + through the notation of indices_image and indices_group concepts. + That is indices_image are always counting from offset in increments of one. as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, identifier_group are not required to be contiguous. + Consequently, indices_group are not required to be contiguous. @@ -110,7 +110,7 @@ - + Link or name of an :ref:`NXdetector` instance with which the data were collected. @@ -371,7 +371,7 @@ - + Group identifier @@ -384,7 +384,7 @@ - + Image identifier @@ -457,7 +457,7 @@ - + Group identifier @@ -470,7 +470,7 @@ - + Image identifier @@ -560,7 +560,7 @@ - + Group identifier @@ -573,7 +573,7 @@ - + Image identifier diff --git a/contributed_definitions/NXinstrument_apm.nxdl.xml b/contributed_definitions/NXinstrument_apm.nxdl.xml index adf3cdf127..e423da1fce 100644 --- a/contributed_definitions/NXinstrument_apm.nxdl.xml +++ b/contributed_definitions/NXinstrument_apm.nxdl.xml @@ -197,7 +197,7 @@ case very efficiently we go for with an array of length 1xn_ions--> - Path to identifier_pulse + Path to pulse_id @@ -212,7 +212,7 @@ case very efficiently we go for with an array of length 1xn_ions--> - Path to identifier_pulse + Path to pulse_id @@ -225,7 +225,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id @@ -235,11 +235,11 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id - + Direct current voltage between the specimen and the (local electrode) in @@ -248,7 +248,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id @@ -274,7 +274,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id @@ -291,7 +291,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id @@ -302,7 +302,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse + Path to pulse_id @@ -313,7 +313,7 @@ existence constraint is independent of other values.--> - Path to identifier_pulse in an instance of :ref:`NXevent_data_apm`. + Path to pulse_id in an instance of :ref:`NXevent_data_apm`. diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 02c6812fab..356c8087d8 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -40,13 +40,13 @@ Base class for documenting the set of atoms of a (molecular) ion. - + A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. + via the service offered as described in id_type. - + How can the identifier be resolved? diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index ff874e36d8..2894354d57 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -29,15 +29,9 @@ Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. + Manual procedures, electro-chemical, or vibropolishing. - - - - Version specifier of this application definition. - - Official NeXus NXDL schema with which this file was written. @@ -46,15 +40,17 @@ - - + + + Sequence index that logically arranges this step along a workflow. + + - - - - + + + @@ -65,14 +61,14 @@ one person or not each person performs all polishing steps--> - + 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. @@ -81,7 +77,7 @@ controlled vocabulary items--> - + Lubricant @@ -90,49 +86,49 @@ also need for free-text in subsequent files?--> 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?--> - + Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs + + If the rotation was controlled manually e.g. by turning knobs on the machine, 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). + + 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 + + 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 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. - @@ -160,7 +156,6 @@ learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk?--> Qualitative statement how the material removal was characterized. - diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 5d4fa57507..efca4d731c 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -144,8 +144,9 @@ The number of line defects.--> The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined - on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. + Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined + on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers + for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. @@ -279,12 +280,12 @@ examples for specific frequently discussed microstructural features--> Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - + First identifier whereby to identify crystals implicitly. - + Identifier whereby to identify each crystal explicitly. @@ -292,12 +293,12 @@ examples for specific frequently discussed microstructural features--> - + First identifier whereby to identify phases implicitly. - + Identifier whereby to identify phase for each crystal explicitly. @@ -376,23 +377,27 @@ examples for specific frequently discussed microstructural features--> How many interfaces are distinguished. - + First identifier whereby to identify interfaces implicitly. - + Identifier whereby to identify each interface explicitly. + + An array with as many entries as interfaces or their projections. - + - Set of pairs of identifier_crystal for each interface. + Set of pairs of indices_crystal values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. @@ -404,9 +409,11 @@ examples for specific frequently discussed microstructural features--> - + - Set of pairs of identifier_phase for each interface. + Set of pairs of indices_phase values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. @@ -419,13 +426,32 @@ examples for specific frequently discussed microstructural features--> - + + + Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional + projections of these as those typically measured in electron microscopy. + In the case of a two-dimensional projection interfaces are interface traces and hence + they have two terminating junctions while in reality the interface is a surface patch + that is bounded by several triple lines. + + Number of triple_junctions adjoining each interface. This array resolves the number of + values along the second dimension for the field indices_triple_junctions. + + + + + + - Set of pairs of identifier_triple_junction for each interface. + Set of pairs of indices_triple_junction for each interface. + + An array with as many tuples along the first dimension i + as interfaces or their projections. + An array with as many values - + @@ -506,12 +532,12 @@ examples for specific frequently discussed microstructural features--> Number of triple junctions. - + First identifier to identify triple junctions implicitly. - + Identifier to identify each triple junction explicitly. @@ -544,7 +570,7 @@ example i) triple points as projections of triple lines have locations--> - + Set of tuples of identifier of crystals connected to the junction for each triple junction. @@ -555,7 +581,7 @@ example i) triple points as projections of triple lines have locations--> - + Set of tuples of identifier of interfaces connected to the junction for each triple junction. @@ -571,7 +597,7 @@ example i) triple points as projections of triple lines have locations--> - + Set of tuples of identifier for polyline segments connected to the junction for each triple junction. @@ -582,7 +608,7 @@ example i) triple points as projections of triple lines have locations--> - The specific identifier_polyline whereby to resolve ambiguities. + The specific indices_polyline whereby to resolve ambiguities. @@ -652,12 +678,12 @@ EXAMPLES FOR DESCRIPTOR VALUES--> Number of quadruple junctions. - + First identifier to identify quadruple junctions implicitly. - + Identifier to identify each quadruple junction explicitly. @@ -691,7 +717,7 @@ example i) quadruple point locations explicitly--> - + Set of tuples of identifier of crystals connected to the junction for each junction. @@ -707,7 +733,7 @@ example i) quadruple point locations explicitly--> - + Set of tuples of identifier of interfaces connected to the junction for each junction. @@ -724,7 +750,7 @@ example i) quadruple point locations explicitly--> - + Set of tuples of identifier for triple junctions connected to the junction for each quadruple junction. @@ -741,7 +767,7 @@ example i) quadruple point locations explicitly--> - + Set of tuples of identifier for phases of crystals connected to the junction for each quadruple junction. diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 8ff6e704ed..0bafa2f716 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -85,7 +85,7 @@ read the next three from input file From which file should the microstructure be instantiated. - + diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index f5aba4d74f..dd9d30a8a1 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -242,14 +242,14 @@ the typical lean summary statistics flattened--> - - + + - - + + @@ -268,10 +268,15 @@ the typical lean summary statistics flattened--> - - + + + + + + + - Set of pairs of identifier_crystal for each interface. + One pair of indices_crystal values for each interface. diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index c7074ace67..eb8c01007e 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -93,7 +93,7 @@ - + Crystal identifier that was assigned to each material point. @@ -140,10 +140,10 @@ - + - + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 50c49766ba..e3809fd32f 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -109,7 +109,7 @@ - + Crystal identifier that was assigned to each material point. @@ -157,16 +157,16 @@ - + - + - + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 81a2d79eba..59e35a363e 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -129,8 +129,7 @@ exists: optional--> The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by identifier_parent or walk through - eventually deeply nested groups in data instances. + these from other sources. @@ -725,7 +724,7 @@ like showing a r(t) plot--> - - + @@ -409,9 +409,9 @@ the typically storage-costlier snapshot data--> - + - Grain identifier for each cell. + Index for each crystal whereby its metadata can be retrieved. @@ -419,9 +419,9 @@ the typically storage-costlier snapshot data--> - + - Identifier of the OpenMP thread which processed this part of the grid. + Identifier of the OpenMP thread that processed this part of the grid. @@ -434,14 +434,14 @@ the typically storage-costlier snapshot data--> - - + + - - + + @@ -522,7 +522,7 @@ the typically storage-costlier snapshot data--> - + Grain identifier assigned to each cell in the recrystallization front. @@ -530,7 +530,7 @@ the typically storage-costlier snapshot data--> - + Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. @@ -539,7 +539,7 @@ the typically storage-costlier snapshot data--> - + Identifier of the OpenMP thread processing each cell in the recrystallization front. diff --git a/contributed_definitions/NXphase.nxdl.xml b/contributed_definitions/NXphase.nxdl.xml index 756ad3edbe..61f5e2032e 100644 --- a/contributed_definitions/NXphase.nxdl.xml +++ b/contributed_definitions/NXphase.nxdl.xml @@ -27,7 +27,7 @@ Instances of phases can be crystalline. - + Identifier for each phase. @@ -37,8 +37,9 @@ The identifier_phase value should match with the integer suffix of the group name which represents that instance in a NeXus/HDF5 file, i.e. - if three phases were used e.g. 0, 1, and 2, three instances of :ref:`NXphase` - named phase0, phase1, and phase2 should be stored in that HDF5 file. + if three phases were used e.g. 0, 1, and 2, three instances of + :ref:`NXphase` named phase0, phase1, and phase2 should be stored + in that HDF5 file. @@ -52,9 +53,25 @@ - + + + + Instance names should use microstructure as a prefix. + + + + + Instance names should use ipf as a prefix. + + + + + Instance names should use pf as a prefix. + + + + + Instance names should use odf as a prefix. + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 6d0fc9e7b7..386f253c9d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -81,14 +81,14 @@ doc: | Reference to a set of features investigated in a cluster analysis. Features need to have disjoint numeric identifier. results for the object set--> - + - Which numerical identifier is the first to be used to label a feature. + Which numerical index is the first to be used to label a feature. The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates that an object belongs to no cluster. - * identifier_offset - 2 indicates that an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used + * index_offset - 1 indicates that an object belongs to no cluster. + * index_offset - 2 indicates that an object belongs to the noise category. + Setting for instance index_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. @@ -97,7 +97,7 @@ results for the object set--> Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance - encode the identifier_cluster. + encode the indices_cluster. @@ -137,7 +137,7 @@ at the level of the feature set--> - + Array of numerical identifier of each feature. diff --git a/contributed_definitions/NXspectrum.nxdl.xml b/contributed_definitions/NXspectrum.nxdl.xml index dd1d91574a..91acac8cac 100644 --- a/contributed_definitions/NXspectrum.nxdl.xml +++ b/contributed_definitions/NXspectrum.nxdl.xml @@ -87,7 +87,7 @@ of the data in this :ref:`NXspectrum` instance. - + Link or name of an :ref:`NXdetector` instance with which the data were collected. @@ -321,7 +321,7 @@ - + Group identifier @@ -334,7 +334,7 @@ - + Spectrum identifier @@ -381,7 +381,7 @@ - + Group identifier @@ -394,7 +394,7 @@ - + Spectrum identifier @@ -468,7 +468,7 @@ - + Group identifier @@ -481,7 +481,7 @@ - + Spectrum identifier diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index cc78b554a4..f99b44117e 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -22,8 +22,8 @@ symbols: Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. These ions get new identifier assigned in the process (the so-called - identifier_evaporation). This identifier must not be confused with - the identifier_pulse. Typically smaller than both p_out and p_out. + evaporation_id). This identifier must not be confused with + the pulse_id. Typically smaller than both p_out and p_out. type: group NXapm(NXobject): (NXentry): @@ -59,7 +59,7 @@ NXapm(NXobject): program(NX_CHAR): \@version(NX_CHAR): - # \@url: + # run_number(NX_UINT): exists: recommended unit: NX_UNITLESS @@ -490,7 +490,7 @@ NXapm(NXobject): Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. - That is identifier_evaporation values take the role of an implicit time and course of the experiment given that + That is evaporation_id values take the role of an implicit time and course of the experiment given that ion extraction physically is a sequential process. There is a number of research groups who build own instruments and share different aspects of their technical @@ -614,7 +614,7 @@ NXapm(NXobject): As set and measured quantities typically change over time and we do not yet know during the measurement which of the events have associated (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the identifier_evaporation but as a + document quantities as a function of the evaporation_id but as a function of the (pulsing) identifier_event. (NXevent_data_apm): exists: ['min', '0', 'max', 'unbounded'] @@ -629,8 +629,8 @@ NXapm(NXobject): exists: recommended # delta_time(NX_NUMBER): - # identifier_pulse_offset(NX_INT): - # identifier_pulse(NX_INT): + # pulse_id_offset(NX_INT): + # pulse_id(NX_INT): instrument(NXinstrument_apm): exists: recommended reflectron(NXcomponent): @@ -850,7 +850,7 @@ NXapm(NXobject): unit: NX_UNITLESS doc: | CRunHeader.fTotalEventRecords - identifier_hit_quality(NX_UINT): + hit_quality(NX_UINT): exists: optional doc: | Identifier used for each hit_quality type. @@ -863,7 +863,7 @@ NXapm(NXobject): unit: NX_UNITLESS doc: | Hit quality identifier for each pulse. - Identifier have to be within identifier_hit_quality. + Identifier have to be within hit_quality. dimensions: rank: 1 dim: (p_out,) @@ -886,7 +886,7 @@ NXapm(NXobject): # used only in the context to learn about the multiplicity of an ion. # pulses_since_last_ion(NX_UINT): # dim: (n,) - # identifier_pulse(NX_INT): + # pulse_id(NX_INT): # dim: (n,) # at this point the original set of events p has been filtered down to p_out hit_spatial_filtering(NXprocess): @@ -903,24 +903,24 @@ NXapm(NXobject): file_name(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - identifier_evaporation_offset(NX_INT): + evaporation_id_offset(NX_INT): unit: NX_UNITLESS doc: | Integer used to name the first pulse to know if there is an - offset of the identifier_evaporation to zero. + offset of the evaporation_id to zero. Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + evaporation_id_offset and cardinality. For example if identifier run from + -2 to 3 the value for evaporation_id_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - identifier_evaporation(NX_INT): + identifier conventions where evaporation_id_offset is 1 and 0 respectively. + evaporation_id(NX_INT): unit: NX_UNITLESS doc: | (Molecular) ion identifier which resolves the sequence in which @@ -1237,7 +1237,7 @@ NXapm(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 15dd4e97600dd4aa116bf8430114eb4f6f8ae4adca2ac24c0896ab0d41cc7609 +# f2f0508164f79388e8c66c86b55e043e8a251b445c02d5c508b0ed122ac8a1d0 # # # +# # # # @@ -1824,7 +1824,7 @@ NXapm(NXobject): # Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme # where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier # i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. -# That is identifier_evaporation values take the role of an implicit time and course of the experiment given that +# That is evaporation_id values take the role of an implicit time and course of the experiment given that # ion extraction physically is a sequential process. # # There is a number of research groups who build own instruments and share different aspects of their technical @@ -1947,7 +1947,7 @@ NXapm(NXobject): # As set and measured quantities typically change over time and we do not # yet know during the measurement which of the events have associated # (molecular) ions that will end up in the reconstructed volume, we must not -# document quantities as a function of the identifier_evaporation but as a +# document quantities as a function of the evaporation_id but as a # function of the (pulsing) identifier_event. # # @@ -1959,8 +1959,8 @@ NXapm(NXobject): # # # +# pulse_id_offset(NX_INT): +# pulse_id(NX_INT):--> # # # @@ -2185,7 +2185,7 @@ NXapm(NXobject): # CRunHeader.fTotalEventRecords # # -# +# # # Identifier used for each hit_quality type. # Following the order of hit_quality_types. @@ -2197,7 +2197,7 @@ NXapm(NXobject): # # # Hit quality identifier for each pulse. -# Identifier have to be within identifier_hit_quality. +# Identifier have to be within hit_quality. # # # @@ -2222,7 +2222,7 @@ NXapm(NXobject): # used only in the context to learn about the multiplicity of an ion. # pulses_since_last_ion(NX_UINT): # dim: (n,) -# identifier_pulse(NX_INT): +# pulse_id(NX_INT): # dim: (n,) # at this point the original set of events p has been filtered down to p_out--> # @@ -2238,25 +2238,25 @@ NXapm(NXobject): # # # -# +# # # Integer used to name the first pulse to know if there is an -# offset of the identifier_evaporation to zero. +# offset of the evaporation_id to zero. # # Identifiers can be defined either implicitly or explicitly. # For implicit indexing identifiers are defined on the interval # :math:`[identifier\_offset, identifier\_offset + c - 1]`. # # Therefore, implicit identifier are completely defined by the value of -# identifier_offset and cardinality. For example if identifier run from -# -2 to 3 the value for identifier_offset is -2. +# evaporation_id_offset and cardinality. For example if identifier run from +# -2 to 3 the value for evaporation_id_offset is -2. # # For explicit indexing the field identifier has to be used. # Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where identifier_offset is 1 and 0 respectively. +# identifier conventions where evaporation_id_offset is 1 and 0 respectively. # # -# +# # # (Molecular) ion identifier which resolves the sequence in which # the ions were evaporated but taking into account that a hit_finding diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 2b134ba74d..1299cef9bf 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -30,7 +30,7 @@ NXapm_compositionspace_config(NXobject): to use for this analysis. type(NX_CHAR): exists: optional - file_path(NX_CHAR): + file_name(NX_CHAR): checksum(NX_CHAR): exists: recommended algorithm(NX_CHAR): @@ -52,7 +52,7 @@ NXapm_compositionspace_config(NXobject): iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. type(NX_CHAR): exists: optional - file_path(NX_CHAR): + file_name(NX_CHAR): checksum(NX_CHAR): exists: recommended algorithm(NX_CHAR): @@ -140,7 +140,7 @@ NXapm_compositionspace_config(NXobject): point. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7fddc5781400cffe09b044d5429d7fe0b455304de680629ca951870bcac17348 +# aab59ee3d2b3ae802fde9bdc282c5679a8a42b98721096d8a915d5f46354f74a # # # -# +# # # For each ion, the identifier of the voxel into which the ion binned. # @@ -536,7 +536,7 @@ NXapm_compositionspace_results(NXobject): # # # -# +# # # Element identifier stored sorted in descending order of feature importance. # diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml index 377c3787fc..80c2de1c22 100644 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_reconstruction.yaml @@ -13,7 +13,7 @@ symbols: Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. These ions get new identifier assigned in the process - the so-called - identifier_evaporation, which must not be confused with the identifier_pulse! + evaporation_id, which must not be confused with the pulse_id! type: group NXapm_reconstruction(NXprocess): @@ -157,7 +157,7 @@ NXapm_reconstruction(NXprocess): algorithms during the histogram computation. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ce13067901785fc95c428e78fece576b9c8a8a1342276e5811d5640cae5dfdbd +# 727135dd0aa1a8ffe91ce6226acf3f61755aefc87396981d1412e1e10b8e9b7d # # # -# +# # -# Identifier for each atom at locations as detailed by position. +# Index for each atom at locations as detailed by position. +# Indices can be used as identifier and thus names for individual atoms. # # # diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml index 455d70f64f..86d224f646 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -13,6 +13,8 @@ doc: | Having an own base class for the data structure how primitives are stored is useful to embrace both users with small or detailed specification demands. + + Indices can be used as identifier and thus names for individual instances. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -56,7 +58,7 @@ NXcg_face_list_data_structure(NXcg_primitive): unit: NX_UNITLESS doc: | Number of faces of the primitives. - identifier_vertex_offset(NX_INT): + index_offset_vertex(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member @@ -64,7 +66,7 @@ NXcg_face_list_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. - identifier_edge_offset(NX_INT): + index_offset_edge(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member @@ -72,7 +74,7 @@ NXcg_face_list_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. - identifier_face_offset(NX_INT): + index_offset_face(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member @@ -80,21 +82,21 @@ NXcg_face_list_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. - identifier_vertex(NX_INT): + indices_vertex(NX_INT): unit: NX_UNITLESS doc: | Integer identifier to distinguish all vertices explicitly. dimensions: rank: 1 dim: (n_v,) - identifier_edge(NX_INT): + indices_edge(NX_INT): unit: NX_UNITLESS doc: | Integer used to distinguish all edges explicitly. dimensions: rank: 1 dim: (n_e,) - identifier_face(NX_INT): + indices_face(NX_INT): unit: NX_UNITLESS doc: | Integer used to distinguish all faces explicitly. @@ -165,7 +167,7 @@ NXcg_face_list_data_structure(NXcg_primitive): dim: (n_f,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5995e7b7684abe457db2bc9ed0f30a7993a6d8e39238eb2e19f454fa18ec19db +# a89812b8950cc4daff0418fe7872a1e2386a204386e6d2be0226beea5a3579ce # # # # @@ -265,7 +269,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # Number of faces of the primitives. # # -# +# # # Integer offset whereby the identifier of the first member # of the vertices differs from zero. @@ -274,7 +278,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # Inspect the definition of NXcg_primitive for further details. # # -# +# # # Integer offset whereby the identifier of the first member # of the edges differs from zero. @@ -283,7 +287,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # Inspect the definition of NXcg_primitive for further details. # # -# +# # # Integer offset whereby the identifier of the first member # of the faces differs from zero. @@ -292,7 +296,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # Inspect the definition of NXcg_primitive for further details. # # -# +# # # Integer identifier to distinguish all vertices explicitly. # @@ -300,7 +304,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # -# +# # # Integer used to distinguish all edges explicitly. # @@ -308,7 +312,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # -# +# # # Integer used to distinguish all faces explicitly. # diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index d80a8a6dd6..be32c90341 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -5,6 +5,8 @@ doc: | Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. The data structure is also known as a doubly connected edge list. + + Indices can be used as identifier and thus names for individual instances. # holes in the polygon mesh can be handled symbols: @@ -46,7 +48,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): dimensions: rank: 1 dim: (n_he,) - identifier_vertex_offset(NX_INT): + index_offset_vertex(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member @@ -54,7 +56,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. - identifier_edge_offset(NX_INT): + index_offset_edge(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member @@ -62,7 +64,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. - identifier_face_offset(NX_INT): + index_offset_face(NX_INT): doc: | Integer offset whereby the identifier of the first member of the faces differs from zero. @@ -70,7 +72,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. - # therefore, identifier_ -vertex, -face, -half_edge are implicit + # therefore, indices_ -vertex, -face, -half_edge are implicit position(NX_NUMBER): unit: NX_ANY doc: | @@ -141,7 +143,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): of microstructural objects like crystals/grains. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6984d4a73236b8d8843788fecf74cd41114a16880a4a9a2f14e78f667a075d41 +# 18d27d46ae4ed64433baf02f09174dc4cc71eac48e42c1d001dcba99dd0ba54c # # # +# # # # The position of the vertices. diff --git a/contributed_definitions/nyaml/NXcg_primitive.yaml b/contributed_definitions/nyaml/NXcg_primitive.yaml index 1717a7e013..087c044d27 100644 --- a/contributed_definitions/nyaml/NXcg_primitive.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive.yaml @@ -29,24 +29,26 @@ NXcg_primitive(NXobject): unit: NX_UNITLESS doc: | The cardinality of the primitive set. Value should be equal to c. - identifier_offset(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the set differs from zero. + Indices can be used as identifiers and thus names of instances. + Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + index_offset and cardinality. For example if identifier run from + -2 to 3 the value for index_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - identifier(NX_INT): + identifier conventions where index_offset is 1 and 0 respectively. + indices(NX_INT): doc: | Identifier of each member for explicit indexing. dimensions: @@ -180,7 +182,7 @@ NXcg_primitive(NXobject): face_normal(NXcg_unit_normal): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aa99ded7f5d1a78a62579d68cb46df21baef3a813e34ec58443605280aa4f10a +# 65f66dd89993d2350d6905134228c02bcc0bb2608e12fadfd29b8e2730de164a # # # # # @@ -504,7 +502,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # Identifier for each pattern. # diff --git a/contributed_definitions/nyaml/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml index aeb47c4793..07c162fcbf 100644 --- a/contributed_definitions/nyaml/NXevent_data_apm.yaml +++ b/contributed_definitions/nyaml/NXevent_data_apm.yaml @@ -8,7 +8,7 @@ doc: | of atom probe research. Against static and dynamic quantities are split to avoid a duplication of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the identifier_pulse field. The point in time when each was issued + These pulses are identified via the pulse_id field. The point in time when each was issued is specified via the combination of start_time and delta_time. Conceptually and technically NeXus currently stores tensorial information as arrays of values @@ -31,10 +31,10 @@ doc: | However, there is no independent logical connection between these two concepts, i.e. temperature and time_stamp. - In the case of atom probe though the time that one would use in NXlog is defined implicitly via identifier_pulse, + In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_id, which is the independent variable vector against which eventually dozens of channels of data are logged. Not only are these channels logged they should ideally also be self-descriptive in that these channels have - identifier_pulse as the independent variable but we do not wish to duplicate this information all the time but + pulse_id as the independent variable but we do not wish to duplicate this information all the time but reference it. Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the @@ -65,16 +65,16 @@ NXevent_data_apm(NXobject): delta_time(NX_NUMBER): unit: NX_TIME doc: | - Delta time array which resolves for each identifier_pulse the time difference + Delta time array which resolves for each pulse_id the time difference between when that pulse was issued and start_time. - In summary, using start_time, end_time, delta_time, identifier_pulse_offset, - and identifier_pulse exactly specifies the connection between when a pulse was + In summary, using start_time, end_time, delta_time, pulse_id_offset, + and pulse_id exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. dimensions: rank: 1 dim: (p,) - identifier_pulse_offset(NX_INT): + pulse_id_offset(NX_INT): unit: NX_UNITLESS doc: | Integer used to name the first pulse to know if there is an @@ -85,19 +85,19 @@ NXevent_data_apm(NXobject): :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. + pulse_id_offset and cardinality. For example if identifier run from + -2 to 3 the value for pulse_id_offset is -2. For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - identifier_pulse(NX_INT): + identifier conventions where pulse_id_offset is 1 and 0 respectively. + pulse_id(NX_INT): unit: NX_UNITLESS doc: | Identifier that contextualizes how the detector and pulser of an atom probe instrument follows a sequence of pulses to trigger field evaporation. - The identifier_pulse is used to associate thus an information about time + The pulse_id is used to associate thus an information about time when quantities have been collected via sampling. In virtually all cases the pulser is a blackbox. Depending on how the @@ -106,24 +106,24 @@ NXevent_data_apm(NXobject): Maybe the first part of the experiment is run at a certain pulse fraction but thereafter the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, identifier_pulse is then an equally + collects all measured values of the pulse_fraction, pulse_id is then an equally long vector which stores the set of events (e.g. pulsing events) when that value was measured. This may cause several situations: In the case that e.g. the pulse_fraction is never changed and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the identifier_pulse e.g. 0 to indicate that the pulse_fraction was set + and a single value for the pulse_id e.g. 0 to indicate that the pulse_fraction was set at the beginning and it was maintained constant during the measurement. If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of identifier_pulse are then [0, 99999] respectively. + pulse onwards. The values of pulse_id are then [0, 99999] respectively. dimensions: rank: 1 dim: (p,) instrument(NXinstrument_apm): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4710a7f12dac9a93c938c8a951dff4466f852d3e6b58591b5af53173ac16ae38 +# 20317c4089aac458ded23af1a3d09887af55ae57a7cc3bf97207fbb434c03eb1 # # # +# # # # Direct current voltage between the specimen and the (local electrode) in @@ -528,7 +528,7 @@ NXinstrument_apm(NXinstrument): # # # -# Path to identifier_pulse +# Path to pulse_id # # # @@ -554,7 +554,7 @@ NXinstrument_apm(NXinstrument): # # # -# Path to identifier_pulse +# Path to pulse_id # # # @@ -571,7 +571,7 @@ NXinstrument_apm(NXinstrument): # # # -# Path to identifier_pulse +# Path to pulse_id # # # @@ -582,7 +582,7 @@ NXinstrument_apm(NXinstrument): # # # -# Path to identifier_pulse +# Path to pulse_id # # # @@ -593,7 +593,7 @@ NXinstrument_apm(NXinstrument): # # # -# Path to identifier_pulse in an instance of :ref:`NXevent_data_apm`. +# Path to pulse_id in an instance of :ref:`NXevent_data_apm`. # # # diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index 3bd3ff33e2..c8ce9a4f45 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -10,11 +10,11 @@ symbols: Number of mass-to-charge-state-ratio range intervals for ion type. type: group NXion(NXobject): - identifier(NX_CHAR): + id(NX_CHAR): doc: | A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - identifier_type(NX_CHAR): + via the service offered as described in id_type. + id_type(NX_CHAR): doc: | How can the identifier be resolved? enumeration: [inchi] @@ -111,7 +111,7 @@ NXion(NXobject): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f85b51ac7b65250a56c2603c5394d8850c9f9874867d6f5bcf4a4c1b70975726 +# 618721fcc0b6c6d769b01a05dffea2144953190c4c0f9f5074a20f8eec35f867 # # # -# -# -# Version specifier of this application definition. -# -# # # # Official NeXus NXDL schema with which this file was written. @@ -177,15 +167,17 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# -# +# +# +# Sequence index that logically arranges this step along a workflow. +# +# # # -# # -# -# -# +# +# +# # # # @@ -196,14 +188,14 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# +# # # 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. @@ -212,7 +204,7 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # -# +# # # Lubricant # @@ -221,49 +213,49 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # 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?--> -# +# # # Qualitative statement how the revelation of the machine was configured. -# If the rotation was controlled manually, e.g. by turning knobs +# +# If the rotation was controlled manually e.g. by turning knobs on the machine, # 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). +# +# 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 +# +# 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 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. # # -# # # # @@ -291,7 +283,6 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # Qualitative statement how the material removal was characterized. # # -# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 4e805d42aa..bc23e0b322 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -48,8 +48,9 @@ doc: | The description attempt here took inspiration from `E. E. Underwood `_ and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined - on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. + Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined + on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers + for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. # , and Volterra line defects (dislocation, disconnection, disclination). symbols: @@ -204,21 +205,21 @@ NXmicrostructure(NXobject): How many phases are distinguished. Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - identifier_offset_crystal(NX_INT): + index_offset_crystal(NX_INT): unit: NX_UNITLESS doc: | First identifier whereby to identify crystals implicitly. - identifier_crystal(NX_INT): + indices_crystal(NX_INT): unit: NX_UNITLESS doc: | Identifier whereby to identify each crystal explicitly. dimensions: dim: (i,) - identifier_offset_phase(NX_INT): + index_offset_phase(NX_INT): unit: NX_UNITLESS doc: | First identifier whereby to identify phases implicitly. - identifier_phase(NX_INT): + indices_phase(NX_INT): unit: NX_UNITLESS doc: | Identifier whereby to identify phase for each crystal explicitly. @@ -280,31 +281,37 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | How many interfaces are distinguished. - identifier_offset(NX_INT): + index_offset_interface(NX_INT): unit: NX_UNITLESS doc: | First identifier whereby to identify interfaces implicitly. - identifier(NX_INT): + indices_interface(NX_INT): unit: NX_UNITLESS doc: | Identifier whereby to identify each interface explicitly. + + An array with as many entries as interfaces or their projections. dimensions: dim: (i,) # topological view, interface specification through the the pair of crystals sharing an interface - identifier_crystal(NX_INT): + indices_crystal(NX_INT): unit: NX_UNITLESS doc: | - Set of pairs of identifier_crystal for each interface. + Set of pairs of indices_crystal values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. dimensions: dim: (i, 2) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. - identifier_phase(NX_INT): + indices_phase(NX_INT): unit: NX_UNITLESS doc: | - Set of pairs of identifier_phase for each interface. + Set of pairs of indices_phase values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. dimensions: dim: (i, 2) \@use_these(NX_CHAR): @@ -312,12 +319,29 @@ NXmicrostructure(NXobject): The specific identifiers whereby to resolve ambiguities. # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface - identifier_triple_junction(NX_INT): + number_of_triple_junctions(NX_UINT): unit: NX_UNITLESS doc: | - Set of pairs of identifier_triple_junction for each interface. + Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional + projections of these as those typically measured in electron microscopy. + In the case of a two-dimensional projection interfaces are interface traces and hence + they have two terminating junctions while in reality the interface is a surface patch + that is bounded by several triple lines. + + Number of triple_junctions adjoining each interface. This array resolves the number of + values along the second dimension for the field indices_triple_junctions. dimensions: - dim: (i, 2) + dim: (n_interfaces,) + indices_triple_junction(NX_INT): + unit: NX_UNITLESS + doc: | + Set of pairs of indices_triple_junction for each interface. + + An array with as many tuples along the first dimension i + as interfaces or their projections. + An array with as many values + dimensions: + dim: (i, j) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. @@ -379,11 +403,11 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | Number of triple junctions. - identifier_offset(NX_INT): + index_offset_triple_junction(NX_INT): unit: NX_UNITLESS doc: | First identifier to identify triple junctions implicitly. - identifier(NX_INT): + indices_triple_junction(NX_INT): unit: NX_UNITLESS doc: | Identifier to identify each triple junction explicitly. @@ -408,7 +432,7 @@ NXmicrostructure(NXobject): Explicit positions. dimensions: dim: (i, d) - identifier_crystal(NX_INT): + indices_crystal(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier of crystals connected to the junction for each @@ -417,7 +441,7 @@ NXmicrostructure(NXobject): dim: (i, 3) # example ii) three interfaces (maybe projections of them) meet at a triple junction - identifier_interface(NX_INT): + indices_interface(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier of interfaces connected to the junction for each @@ -429,7 +453,7 @@ NXmicrostructure(NXobject): The specific interface identifiers whereby to resolve ambiguities. # example iii) three polyline segments meet at a triple junction, polyline segments of discretized interface segments - identifier_polyline(NX_INT): + indices_polyline(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier for polyline segments connected to the junction for @@ -438,7 +462,7 @@ NXmicrostructure(NXobject): dim: (i, 3) \@use_these(NX_CHAR): doc: | - The specific identifier_polyline whereby to resolve ambiguities. + The specific indices_polyline whereby to resolve ambiguities. # example iv) e.g. crystals of three different phases meet at a triple junction # EXAMPLES FOR DESCRIPTOR VALUES @@ -490,11 +514,11 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | Number of quadruple junctions. - identifier_offset(NX_INT): + index_offset_quadruple_junction(NX_INT): unit: NX_UNITLESS doc: | First identifier to identify quadruple junctions implicitly. - identifier(NX_INT): + indices_quadruple_junction(NX_INT): unit: NX_UNITLESS doc: | Identifier to identify each quadruple junction explicitly. @@ -521,7 +545,7 @@ NXmicrostructure(NXobject): dim: (i, 3) # example ii) four crystals meet at a quadruple junction - identifier_crystal(NX_INT): + indices_crystal(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier of crystals connected to the junction for each @@ -532,7 +556,7 @@ NXmicrostructure(NXobject): doc: | The specific identifier to instances of crystal identifiers whereby to resolve ambiguities. - identifier_interface(NX_INT): + indices_interface(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier of interfaces connected to the junction for each @@ -545,7 +569,7 @@ NXmicrostructure(NXobject): ambiguities. # example iii) e.g. three triple lines meet at a quadruple junction - identifier_triple_junction(NX_INT): + indices_triple_junction(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier for triple junctions connected to the junction for @@ -558,7 +582,7 @@ NXmicrostructure(NXobject): resolve ambiguities. # example iv) crystals of eventually four different phases meet at a quadruple junction - identifier_phase(NX_INT): + indices_phase(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier for phases of crystals connected to the junction for @@ -591,7 +615,7 @@ NXmicrostructure(NXobject): dim: (i,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84d8c2f6696f28eed47ae75be59289a30fcbf06ac278930fe277d1896badd2a8 +# d70ed9610c7e4918d068e2d4a7a4375e1698e3a3ced0a087fc29bbafc244b580 # # # @@ -873,12 +898,12 @@ NXmicrostructure(NXobject): # Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. # # -# +# # # First identifier whereby to identify crystals implicitly. # # -# +# # # Identifier whereby to identify each crystal explicitly. # @@ -886,12 +911,12 @@ NXmicrostructure(NXobject): # # # -# +# # # First identifier whereby to identify phases implicitly. # # -# +# # # Identifier whereby to identify phase for each crystal explicitly. # @@ -970,23 +995,27 @@ NXmicrostructure(NXobject): # How many interfaces are distinguished. # # -# +# # # First identifier whereby to identify interfaces implicitly. # # -# +# # # Identifier whereby to identify each interface explicitly. +# +# An array with as many entries as interfaces or their projections. # # # # # # -# +# # -# Set of pairs of identifier_crystal for each interface. +# Set of pairs of indices_crystal values, for each interface one value pair. +# +# An array with as many pairs as interfaces or their projections. # # # @@ -998,9 +1027,11 @@ NXmicrostructure(NXobject): # # # -# +# # -# Set of pairs of identifier_phase for each interface. +# Set of pairs of indices_phase values, for each interface one value pair. +# +# An array with as many pairs as interfaces or their projections. # # # @@ -1013,13 +1044,32 @@ NXmicrostructure(NXobject): # # # -# +# # -# Set of pairs of identifier_triple_junction for each interface. +# Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional +# projections of these as those typically measured in electron microscopy. +# In the case of a two-dimensional projection interfaces are interface traces and hence +# they have two terminating junctions while in reality the interface is a surface patch +# that is bounded by several triple lines. +# +# Number of triple_junctions adjoining each interface. This array resolves the number of +# values along the second dimension for the field indices_triple_junctions. +# +# +# +# +# +# +# +# Set of pairs of indices_triple_junction for each interface. +# +# An array with as many tuples along the first dimension i +# as interfaces or their projections. +# An array with as many values # # # -# +# # # # @@ -1100,12 +1150,12 @@ NXmicrostructure(NXobject): # Number of triple junctions. # # -# +# # # First identifier to identify triple junctions implicitly. # # -# +# # # Identifier to identify each triple junction explicitly. # @@ -1138,7 +1188,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier of crystals connected to the junction for each # triple junction. @@ -1149,7 +1199,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier of interfaces connected to the junction for each # triple junction. @@ -1165,7 +1215,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier for polyline segments connected to the junction for # each triple junction. @@ -1176,7 +1226,7 @@ NXmicrostructure(NXobject): # # # -# The specific identifier_polyline whereby to resolve ambiguities. +# The specific indices_polyline whereby to resolve ambiguities. # # # @@ -1246,12 +1296,12 @@ NXmicrostructure(NXobject): # Number of quadruple junctions. # # -# +# # # First identifier to identify quadruple junctions implicitly. # # -# +# # # Identifier to identify each quadruple junction explicitly. # @@ -1285,7 +1335,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier of crystals connected to the junction for each # junction. @@ -1301,7 +1351,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier of interfaces connected to the junction for each # junction. @@ -1318,7 +1368,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier for triple junctions connected to the junction for # each quadruple junction. @@ -1335,7 +1385,7 @@ NXmicrostructure(NXobject): # # # -# +# # # Set of tuples of identifier for phases of crystals connected to the junction for # each quadruple junction. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index c913acb042..9f8c22ca95 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -56,7 +56,7 @@ NXmicrostructure_gragles_config(NXobject): doc: | From which file should the microstructure be instantiated. type: - identifier: + file_name: algorithm: checksum: edge_length(NX_FLOAT): @@ -284,7 +284,7 @@ NXmicrostructure_gragles_config(NXobject): # # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 98d39a09a15b012a1cde431e9a83bfbf35dea5f844294b32b6cdd87826cbb53c +# 2937adc715e78fe6bbf5ad57d09e76ad2aa4dd3eb9782c8ddacd0bd6bffc4e80 # # # -# +# # # # -# +# # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 07b0c3dc84..c96a3b1d81 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -66,8 +66,7 @@ NXmicrostructure_score_config(NXobject): The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by identifier_parent or walk through - eventually deeply nested groups in data instances. + these from other sources. program1(NXprogram): exists: recommended doc: | @@ -535,7 +534,7 @@ NXmicrostructure_score_config(NXobject): Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. - # identifier_domain(NX_UINT): + # domain_id(NX_UINT): # doc: | # List of identifier for those CAs domains which should be sampled. # Identifier start from 1. @@ -543,7 +542,7 @@ NXmicrostructure_score_config(NXobject): # dim: (n_su,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 03ff6c1cc0bd458dd25c5847ee92f44c307e0f1cc54c41ac6f07e702b5ef5d01 +# d1f865893862461687a1900d872e593b85102b0258a35b84ec6f336cf04a8260 # # # # -# +# # -# Grain identifier for each cell. +# Index for each crystal whereby its metadata can be retrieved. # # # @@ -857,9 +857,9 @@ NXmicrostructure_score_results(NXobject): # # # -# +# # -# Identifier of the OpenMP thread which processed this part of the grid. +# Identifier of the OpenMP thread that processed this part of the grid. # # # @@ -872,14 +872,14 @@ NXmicrostructure_score_results(NXobject): # # # -# -# +# +# # # # # -# -# +# +# # # # @@ -960,7 +960,7 @@ NXmicrostructure_score_results(NXobject): # # # -# +# # # Grain identifier assigned to each cell in the recrystallization front. # @@ -968,7 +968,7 @@ NXmicrostructure_score_results(NXobject): # # # -# +# # # Grain identifier assigned to each nucleus which affected that cell in the # recrystallization front. @@ -977,7 +977,7 @@ NXmicrostructure_score_results(NXobject): # # # -# +# # # Identifier of the OpenMP thread processing each cell in the recrystallization # front. diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml index 28a34032e1..c047016bc6 100644 --- a/contributed_definitions/nyaml/NXphase.yaml +++ b/contributed_definitions/nyaml/NXphase.yaml @@ -5,7 +5,7 @@ doc: | Instances of phases can be crystalline. type: group NXphase(NXobject): - identifier(NX_INT): + phase_identifier(NX_INT): unit: NX_UNITLESS doc: | Identifier for each phase. @@ -16,8 +16,9 @@ NXphase(NXobject): The identifier_phase value should match with the integer suffix of the group name which represents that instance in a NeXus/HDF5 file, i.e. - if three phases were used e.g. 0, 1, and 2, three instances of :ref:`NXphase` - named phase0, phase1, and phase2 should be stored in that HDF5 file. + if three phases were used e.g. 0, 1, and 2, three instances of + :ref:`NXphase` named phase0, phase1, and phase2 should be stored + in that HDF5 file. name(NX_CHAR): doc: | Given name as an alias for identifying this phase. @@ -30,13 +31,21 @@ NXphase(NXobject): (NXatom): # support for microstructures that are not proposed to the NIAC in this PR - # - # - # - # + (NXmicrostructure): + doc: | + Instance names should use microstructure as a prefix. + (NXmicrostructure_ipf): + doc: | + Instance names should use ipf as a prefix. + (NXmicrostructure_pf): + doc: | + Instance names should use pf as a prefix. + (NXmicrostructure_odf): + doc: | + Instance names should use odf as a prefix. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bd0bd662fe6f1dbbf69709a777bf20916ec8caf8345b2d5461e18901d3f4631a +# fe2c45a22774ad41e780447e397a12ce1afcdd58e5a776514d651cd29bb0e716 # # # # # -# +# +# +# +# Instance names should use microstructure as a prefix. +# +# +# +# +# Instance names should use ipf as a prefix. +# +# +# +# +# Instance names should use pf as a prefix. +# +# +# +# +# Instance names should use odf as a prefix. +# +# # diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml index c4ed784a76..2e77813737 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -43,15 +43,15 @@ NXsimilarity_grouping(NXobject): # Reference to a set of features investigated in a cluster analysis. # Features need to have disjoint numeric identifier. # results for the object set - identifier_offset(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | - Which numerical identifier is the first to be used to label a feature. + Which numerical index is the first to be used to label a feature. The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates that an object belongs to no cluster. - * identifier_offset - 2 indicates that an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used + * index_offset - 1 indicates that an object belongs to no cluster. + * index_offset - 2 indicates that an object belongs to the noise category. + Setting for instance index_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. numerical_label(NX_INT): @@ -59,7 +59,7 @@ NXsimilarity_grouping(NXobject): doc: | Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance - encode the identifier_cluster. + encode the indices_cluster. dimensions: rank: 2 dim: (c, n_lbl_num) @@ -91,7 +91,7 @@ NXsimilarity_grouping(NXobject): # Total number of features (excluding noise and unassigned) can be trivially computed # when knowing total, noise, and unassigned. - identifier(NX_UINT): + indices_cluster(NX_INT): unit: NX_UNITLESS doc: | Array of numerical identifier of each feature. @@ -107,7 +107,7 @@ NXsimilarity_grouping(NXobject): dim: (n_features, n_lbl_num) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fd3fd73b31468157882806dbc82824eb02fb222b6d4584196bcbb1f06ce4a62a +# d8b60f631586563552d4c727bb793166be42362ae44212106629ea2b4d58e3c0 # # # -# +# # -# Which numerical identifier is the first to be used to label a feature. +# Which numerical index is the first to be used to label a feature. # # The value should be chosen in such a way that special values can be resolved: -# * identifier_offset - 1 indicates that an object belongs to no cluster. -# * identifier_offset - 2 indicates that an object belongs to the noise category. -# Setting for instance identifier_offset to 1 recovers the commonly used +# * index_offset - 1 indicates that an object belongs to no cluster. +# * index_offset - 2 indicates that an object belongs to the noise category. +# Setting for instance index_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. # @@ -207,7 +207,7 @@ NXsimilarity_grouping(NXobject): # # Matrix of numerical label for each member in the set. # For classical clustering algorithms this can for instance -# encode the identifier_cluster. +# encode the indices_cluster. # # # @@ -247,7 +247,7 @@ NXsimilarity_grouping(NXobject): # # -# +# # # Array of numerical identifier of each feature. # diff --git a/contributed_definitions/nyaml/NXspectrum.yaml b/contributed_definitions/nyaml/NXspectrum.yaml index 058dcbbf62..debe95496d 100644 --- a/contributed_definitions/nyaml/NXspectrum.yaml +++ b/contributed_definitions/nyaml/NXspectrum.yaml @@ -43,7 +43,7 @@ NXspectrum(NXobject): doc: | Imaging (data collection) mode of the instrument during acquisition of the data in this :ref:`NXspectrum` instance. - identifier_detector(NX_CHAR): + detector_identifier(NX_CHAR): doc: | Link or name of an :ref:`NXdetector` instance with which the data were collected. @@ -213,7 +213,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Counts - identifier_group(NX_INT): + indices_group(NX_INT): unit: NX_UNITLESS doc: | Group identifier @@ -223,7 +223,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Group identifier - identifier_spectrum(NX_INT): + indices_spectrum(NX_INT): unit: NX_UNITLESS doc: | Spectrum identifier @@ -256,7 +256,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Counts - identifier_group(NX_INT): + indices_group(NX_INT): unit: NX_UNITLESS doc: | Group identifier @@ -266,7 +266,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Group identifier - identifier_spectrum(NX_INT): + indices_spectrum(NX_INT): unit: NX_UNITLESS doc: | Spectrum identifier @@ -319,7 +319,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Counts - identifier_group(NX_INT): + indices_group(NX_INT): unit: NX_UNITLESS doc: | Group identifier @@ -329,7 +329,7 @@ NXspectrum(NXobject): \@long_name(NX_CHAR): doc: | Group identifier - identifier_spectrum(NX_INT): + indices_spectrum(NX_INT): unit: NX_UNITLESS doc: | Spectrum identifier @@ -381,7 +381,7 @@ NXspectrum(NXobject): Energy # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 91123fe7597e0b37491dd77054f1239488647f7286a2c2393b2bf08e419b5483 +# 68227c894efa4e970e8826facd84d2676cd89a1a8de369b7af5df2856417c3e6 # # # CRunHeader.fTotalEventRecords - + - Identifier used for each hit_quality type. - Following the order of hit_quality_types. + Hit quality is an integer that specifies which category/type a hit was assigned to. + This field lists the human-readable, possibly though proprietary types distinguished. + The indices of this array are used in hit_quality to encode hit_quality for each + pulse in a more efficient way than by repeating the string that is used for each + type as it is provided in this field. + + As an example assume two types golden and partial are distinguished. + If hit_quality_type stores the array "golden", "partial", the index 0 + in hit_quality identifies all those pulses of category golden, + while the index 1 in hit_quality identifies all of category partial. diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 960f1a2acf..42f8dd0378 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -44,9 +44,9 @@ Application definition for results of the CompositionSpace tool used in atom probe. - + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the CompositionSpace software using NeXus. @@ -100,7 +100,7 @@ for if desired all the dependencies and libraries--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources pointed to by identifier_parent or walk through @@ -113,7 +113,7 @@ for if desired all the dependencies and libraries--> Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that was ranged for each ion. - + Using a discretization grid that is larger than the average distance between reconstructed ion positions reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods used in atom probe for characterizing microstructural features that use the ion position data directly. @@ -170,7 +170,7 @@ for if desired all the dependencies and libraries--> - + For each ion, the identifier of the voxel into which the ion binned. @@ -301,7 +301,7 @@ for if desired all the dependencies and libraries--> Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - + Instances should use cluster_analysis as a name prefix. @@ -378,7 +378,7 @@ for if desired all the dependencies and libraries--> The maximum distance between voxel pairs in a neighborhood to be considered connected. - + Instances should use dbscan as a name prefix. @@ -399,7 +399,7 @@ for if desired all the dependencies and libraries--> Voxel identifier - + Using these identifiers correlated element-wise with the values in the label array specifies for which voxel in the grid clusters from this process were found. @@ -418,7 +418,4 @@ for if desired all the dependencies and libraries--> - diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index abab0e3805..de2b6cd24e 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -46,7 +46,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> Application definition for a configuration file of the paraprobe-clusterer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -113,7 +113,7 @@ the region of interest.--> This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - + Instances should use cluster_analysis as a name prefix. @@ -146,7 +146,7 @@ the region of interest.--> - + @@ -154,7 +154,7 @@ the region of interest.--> - + @@ -162,7 +162,7 @@ the region of interest.--> - + @@ -175,9 +175,6 @@ the region of interest.--> - @@ -193,28 +190,28 @@ identifier(NX_UINT):--> How should iontypes be considered during the cluster analysis. - + 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 nuclide structure. - + The value resolve_element will set an ion active and account as many times for it, as the (molecular) ion contains atoms of elements in the whitelist ion_query_nuclide_vector. - + The value resolve_isotope will set an ion active and account as many times for it, as the (molecular) ion contains nuclides in the whitelist ion_query_nuclide_vector. - + In effect, ion_query_nuclide_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 an ion of a molecular ion with more than one nuclide, say Ti O for example is counted potentially several times because at that position (reconstructed) position it has been assumed that @@ -243,10 +240,10 @@ identifier(NX_UINT):--> Settings for DBScan clustering algorithm. For original details about the algorithm 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>`_ @@ -254,16 +251,16 @@ identifier(NX_UINT):--> Strategy how a set of cluster analyses with different parameter is executed: - + * For tuple as many runs are performed as parameter values have been defined. * For combinatorics individual parameter arrays are looped over. - + As an example we may provide ten entries for eps and three entries for min_pts. If high_throughput_method is set to tuple, the analysis is invalid because we have an insufficient number of min_pts values to pair them with our ten eps values. By contrast, if high_throughput_method is set to combinatorics, the tool will run three individual min_pts runs for each eps value, resulting in a total of 30 analyses. - + A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. @@ -314,10 +311,10 @@ dim: (j,)--> 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. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index e2e4349c72..1d73c8dc59 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -39,7 +39,7 @@ Application definition for results files of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -68,7 +68,7 @@ Results of a DBScan clustering analysis. - + Instances should use dbscan as a name prefix. @@ -81,7 +81,7 @@ The minimum points (min_pts) parameter used. - + Number of members in the set which is partitioned into features. Specifically, this is the total number of targets filtered from the @@ -89,22 +89,22 @@ for sure not necessarily 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 + * index_offset - 1 indicates an object belongs to no cluster. + * index_offset - 2 indicates an object belongs to the noise category. + + Setting for instance index_offset to 1 recovers the commonly used case that objects of the noise category get the value of -1 and points of the unassigned category get the value 0. - The evaporation (sequence) identifier (aka identifier_evaporation) to figure out + The evaporation (sequence) id (aka evaporation_id) to figure out which ions from the reconstruction were considered targets. The length of this array is not necessarily n_ions. Instead, it is the value of cardinality. @@ -168,7 +168,7 @@ Weights for each target that specifies how probable the target is assigned to a specific cluster. - + For the DBScan algorithm and atom probe tomography this value is 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 @@ -178,11 +178,6 @@ - Are targets assigned to the noise category or not. @@ -191,11 +186,6 @@ number_of_objects(NX_UINT): - Are targets assumed a core point. @@ -211,18 +201,18 @@ number_of_objects(NX_UINT): cluster were found. - + Total number of targets in the set, i.e. ions that were filtered and considered in this cluster analysis. - + 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. @@ -233,15 +223,15 @@ number_of_objects(NX_UINT): - + - Numerical identifier of each feature aka identifier_cluster. + Numerical identifier of each feature aka cluster_id. - + Number of members for each feature. @@ -265,9 +255,9 @@ number_of_objects(NX_UINT): - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 8a5cc44108..4a6cf8f3a8 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -29,7 +29,7 @@ Application definition for a configuration file of the paraprobe-distancer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -62,7 +62,7 @@ - + @@ -70,7 +70,7 @@ - + @@ -78,7 +78,7 @@ - + @@ -89,9 +89,7 @@ - - + @@ -109,7 +107,7 @@ Specifies for which point the tool will compute distances. - + The value *default* configures that distances are computed for all points. The value *skin* configures that distances are computed only for those points which are not farther away located to a triangle than @@ -139,9 +137,9 @@ Each triangle_set that is referred to here should be a face_list_data_structure, i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - + Instances should use triangle_set as a name prefix. @@ -172,7 +170,7 @@ of facet normal vectors for the triangles in that triangle_set. - + Absolute path in the (HDF5) file that points to the array of identifier for the triangles in that triangle_set. diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 163adca0de..19d8b577bc 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -39,16 +39,16 @@ Application definition for results files of the paraprobe-distancer tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the distance is computed as the projected distance, this tool evaluates robustly the exact distance between a point and a triangle. - + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. - + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, what their topology is, or whether or not these triangles are consistently oriented. @@ -83,16 +83,16 @@ - + For each point the identifier of the triangle for which the - shortest distance was found + shortest distance was found. - + A support field to enable the visualization of each point by an explicit identifier on the interval [0, n_ions - 1]. @@ -108,7 +108,7 @@ A bitmask that identifies which of the distance values is assumed to have a consistent sign because the closest triangle had a consistent outer unit normal defined. - + For points whose bit is set to 0 the distance is correct but the sign is not reliable. @@ -165,9 +165,9 @@ triangles in this case--> - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 095e23e4ef..83473e73fe 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -34,7 +34,7 @@ Application definition for a configuration file of the paraprobe-intersector tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -54,13 +54,13 @@ Tracking volume_volume_spatial_correlations (v_v) is the process of building logical relations between objects, their proximity and eventual volumetric intersections. Here, objects are assumed to be represented as a set of triangulated surface meshes. - + 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 :math:`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. - + Instances should use v_v_spatial_correlation as a name prefix. @@ -69,14 +69,14 @@ 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>`_, it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron intersections in paraprobe-intersector. @@ -130,7 +130,7 @@ 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 can be interpreted as the time/iteration (i.e. :math:`k`) step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). @@ -182,7 +182,7 @@ - + Array of identifier whereby the path to the geometry data can be inferred automatically. @@ -200,7 +200,7 @@ 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 current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). @@ -247,7 +247,7 @@ - + Array of identifier whereby the path to the geometry data can be inferred automatically. diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 7b48475bcc..daaa3390cf 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -59,7 +59,7 @@ Application definition for results files of the paraprobe-intersector tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -77,7 +77,7 @@ - A matrix of identifier_feature that specifies which named features + A matrix of indices_feature that specifies which named features from the current_set have directed link(s) pointing to which named feature(s) from the next_set. @@ -98,7 +98,7 @@ - A matrix of identifier_feature which specifies which named feature(s) + A matrix of indices_feature 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 are defined is symmetric it holds that next_to_current maps @@ -134,32 +134,32 @@ 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, pair relations - are analyzed with respect to which objects with identifier_feature + are analyzed with respect to which objects with indices_feature cluster in identifier space. Thereby, a logical connection (link) is established between the features in the current_set and the next_set. Recall that these two sets 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 for precipitates B. - + Coprecipitation analysis now logically connects these independent characterization results to establish spatial correlations of e.g. the precipitates' spatial arrangement. - Matrix of identifier_feature and identifier_cluster pairs which - encodes the cluster to which each identifier_feature was assigned. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. Here for features of the current_set. @@ -169,8 +169,8 @@ - Matrix of identifier_feature and identifier_cluster pairs which - encodes the cluster to which each identifier_feature was assigned. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. Here for features of the next_set. @@ -178,7 +178,7 @@ - + The identifier (names) of the cluster. @@ -191,10 +191,10 @@ 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 third column encodes the total number of members in the cluster. @@ -205,10 +205,10 @@ 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. @@ -238,9 +238,9 @@ - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index b4956764ae..0751e86a89 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -69,7 +69,7 @@ Application definition for a configuration file of the paraprobe-nanochem tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -83,10 +83,10 @@ Discretization and distributing of the ion point cloud on a 3D grid to enable continuum-scale analyses. - + By default, the tool computes a full kernel density estimation of decomposed ions to create one discretized field for each element. - + One delocalization task configures a parameter sweep with at least one delocalization. The total number of runs depends on the number of grid_resolution and kernel_variance values. For example, setting two grid_resolutions @@ -150,7 +150,7 @@ This can be achieved with the load_existent option.--> - + @@ -158,7 +158,7 @@ This can be achieved with the load_existent option.--> - + @@ -166,7 +166,7 @@ This can be achieved with the load_existent option.--> - + @@ -259,25 +259,25 @@ identifier(NX_UINT):--> times an ion is to be counted. The tool performs a so-called atomic decomposition of all iontypes, i.e. the tool analyses from how many atoms of each nuclide or element respectively an (molecular) ion is built from. - + Taking the hydroxonium H3O+ molecular ion as an example: It contains hydrogen and oxygen atoms. The multiplicity of hydrogen is three whereas that of oxygen is one. Therefore, the respective atomic decomposition analysis prior to the iso-surface computation adds three hydrogen counts for each H3O+ ion. - + This is a practical solution which accepts that on the one hand not every bond is broken during an atom probe experiment but also that ions may react further during their flight to the detector. The exact details depend on the local field conditions, quantum mechanics of possible electron transfer and thus the detailed trajectory of the system and its electronic state. - + The detection of molecular ions instead of always single atom ions only is the reason that an atom probe experiment tells much about field evaporation physics but also faces an inherent loss of information with respect to the detailed spatial arrangement that is independent of other imprecisions such as effect of limited accuracy of reconstruction protocols and their parameterization. - + Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. @@ -349,11 +349,11 @@ identifier(NX_UINT):--> composition-normalized delocalization. Here, it is possible that the composition increases towards the edge of the dataset because the quotient of two numbers that 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, keep_edge_triangles instructs the tool to not remove triangles at the edge of the dataset at the cost of bias. When using this keep_edge_triangles users should understand that all features in contact with the edge of the dataset get usually @@ -364,12 +364,12 @@ identifier(NX_UINT):--> of grain shapes via orientation microscopy from electron microscopy or X-ray diffraction tomography. Features at the edge of the dataset may have not been captured fully. - + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, paraprobe-nanochem implements a complete pipeline to process features at the edge of the dataset. Specifically, these are modelled and replaced with closed polyhedral objects using an iterative mesh and hole-filling procedures with fairing operations. - + The tool bookkeeps such objects separately to lead the decision whether or not to consider these objects to the user. Users should be aware that results from fairing operations should be compared to results from analyses where all objects at the edge @@ -379,7 +379,7 @@ identifier(NX_UINT):--> deliver statistically significant results for compositions, this does not necessarily mean that same dataset will also yield statistically significant and insignificantly biased results for 3D 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. @@ -392,7 +392,7 @@ identifier(NX_UINT):--> The ion-to-surface distance that is used in the analyses of features to identify whether these are laying inside the dataset or close to the surface (edge) of the dataset. - + If an object has at least one ion with an ion-to-surface-distance below this threshold, the object is considered close to the edge of the dataset. The tool uses a distance-based approach to solve the in general complicated and involved treatment of computing @@ -401,7 +401,7 @@ identifier(NX_UINT):--> robustness issues as a consequence of which a mesh can be detected as being completely inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost touching only the edge (e.g. from inside). - + Practically, humans would likely still 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 flexible. @@ -412,7 +412,7 @@ identifier(NX_UINT):--> Iso-contour values. For each value, the tool computes an iso-surface and performs subsequent analyses for each iso-surface. 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.-% @@ -424,7 +424,7 @@ identifier(NX_UINT):--> Specifies if the tool should report the triangle soup which represents each triangle of the iso-surface complex. The resulting set of triangles is colloquially referred to as a soup because different sub-set may not be connected. - + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) the triangle belongs. The clustering of triangles within the soup is performed with a modified DBScan algorithm. @@ -435,12 +435,12 @@ identifier(NX_UINT):--> 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 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 scandium-rich precipitates in aluminum alloys which in reconstructions may appear as ellipsoids although they should be indeed almost spherical @@ -452,7 +452,7 @@ identifier(NX_UINT):--> 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 tiny sub-complexes (e.g. small isolated tetrahedra). - + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid on which marching cubes operates. Such objects may not contain an ion; especially when considering that delocalization procedures smoothen the positions of the ions. Although these small objects are @@ -473,7 +473,7 @@ identifier(NX_UINT):--> 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). - + Users should be aware that the choice of the algorithm to compute the bounding box can have an effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms @@ -485,7 +485,7 @@ identifier(NX_UINT):--> Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector tool to infer if two objects share common ions, which is then understood as 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 and flat face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of @@ -493,7 +493,7 @@ identifier(NX_UINT):--> might be so small or happening in the volume between two reconstructed ion positions. Consequently, sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections between objects. - + 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 @@ -514,7 +514,7 @@ identifier(NX_UINT):--> Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose combinatorial analysis according to has_object returned 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 feature. In most cases objects, precipitates in atom probe end up as open objects because they have been clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account @@ -561,7 +561,7 @@ identifier(NX_UINT):--> via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. Otherwise, the ROI is assumed to make no edge contact. - + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant provided constructions such as alpha shapes or alpha wrappings (such as paraprobe-surfacer does) about the @@ -578,7 +578,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> Use a principle component analysis (PCA) to mesh a single free-standing interface patch within the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). - + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess in cases when closed objects constructed from patches e.g. iso-surfaces are not available or when there is no substantial or consistently oriented concentration gradients across an interface @@ -586,7 +586,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> within the point cloud is insufficient or when combined with interface_meshing based on ion density traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). - + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations paraprobe-nanochem uses inspection functionalities which detect potential geometric inconsistencies or self-interactions of the evolved DCOM mesh. @@ -635,7 +635,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> - + @@ -643,7 +643,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> - + @@ -651,7 +651,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> - + @@ -682,11 +682,11 @@ identifier(NX_UINT):--> How is the PCA initialized: - + * 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>`_ creates a control_point_file that can be parsed by paraprobe-parmsetup-nanochem to match the here required @@ -763,7 +763,7 @@ identifier(NX_UINT):--> 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 might be relocated. - + The larger it is the DCOM radius in relation to the target_edge_length the more likely it becomes that vertices will be relocated so substantially that triangle self-intersections may occur. The tool detects these and stops in a controlled @@ -792,21 +792,21 @@ identifier(NX_UINT):--> Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying interfacial excess or for performing classical composition analyses. - + The tool will test for each ROIs if it is completely embedded in the dataset. Specifically, each such test evaluates if the ROI cuts at least one triangle of the triangulated surface mesh that is referred to by surface. If this is the case the ROI is marked as one close to the surface and not analyzed further. Otherwise, the ROI is marked as one far from the surface and processed further. - + For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into nuclides as many times as their respective multiplicity. For each processed ROI the tool stores a sorted list of signed distance values to enable post-processing with other software like e.g. reporter to perform classical Krakauer/Seidman-style interfacial excess analyses. - + Users should be aware that the latter intersection analysis is not a volumetric intersection analysis. Given that the triangulated mesh referred to in surface is not required to mesh neither a watertight @@ -943,7 +943,7 @@ from normals of neighboring facets, type of weighting schemes can affect results - + @@ -951,7 +951,7 @@ from normals of neighboring facets, type of weighting schemes can affect results - + @@ -959,7 +959,7 @@ from normals of neighboring facets, type of weighting schemes can affect results - + @@ -998,7 +998,7 @@ identifier(NX_UINT):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 9384f40fcd..a40f1a9ad4 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -86,7 +86,7 @@ The cardinality/total number of triangles in the triangle soup.--> Application definition for results files of the paraprobe-nanochem tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -131,14 +131,14 @@ The cardinality/total number of triangles in the triangle soup.--> The discretized domain/grid on which the delocalization is applied. - + - + The total number of cells/voxels of the grid. @@ -179,7 +179,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + 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 @@ -232,7 +232,7 @@ The cardinality/total number of triangles in the triangle soup.--> 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. @@ -242,7 +242,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + Integer which specifies the first index to be used for distinguishing identifiers for vertices. Identifiers are defined either implicitly or explicitly. @@ -251,7 +251,7 @@ The cardinality/total number of triangles in the triangle soup.--> 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. @@ -279,12 +279,12 @@ The cardinality/total number of triangles in the triangle soup.--> 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -324,7 +324,7 @@ The cardinality/total number of triangles in the triangle soup.--> The boundary conditions for each boundary: - + 0 - undefined 1 - open 2 - periodic @@ -343,10 +343,10 @@ The cardinality/total number of triangles in the triangle soup.--> The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. - + If the intensity for all matches of the weighting_model are summarized name this NXdata instance scalar_field_magn_total. - + If the intensity is reported for each iontype one can avoid many subsequent computations as individual intensities can be reinterpreted using a different weighting_model in down-stream usage of the here reported values (e.g. with Python scripting). @@ -502,12 +502,12 @@ The cardinality/total number of triangles in the triangle soup.--> An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - + Instances should iso_surface as a name prefix. - + For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. - + This yields a complex of not necessarily connected geometric primitives. Paraprobe-nanochem approximates this complex with a soup of triangles. @@ -530,15 +530,9 @@ The cardinality/total number of triangles in the triangle soup.--> 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 :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - + + + @@ -547,7 +541,7 @@ The cardinality/total number of triangles in the triangle soup.--> Positions of the vertices. - + Users are encouraged to reduce the vertices to a unique set as this may result in a more efficient storage of the geometry data. It is also possible though to store the vertex positions naively in which @@ -562,12 +556,12 @@ The cardinality/total number of triangles in the triangle soup.--> 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -600,7 +594,7 @@ The cardinality/total number of triangles in the triangle soup.--> Qualifier how which specifically oriented normal to its primitive each normal represents. - + * 0 - undefined * 1 - outer * 2 - inner @@ -626,7 +620,7 @@ exists: optional--> Qualifier how which specifically oriented normal to its primitive each normal represents. - + * 0 - undefined * 1 - outer * 2 - inner @@ -714,9 +708,9 @@ dim: (k,)--> This may yield a set of connected features whose individual surfaces are discretized by a triangulated mesh each. Such volumetric features can be processed further using paraprobe-nanochem using a workflow with at most two steps. - + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. These objects were already watertight within the triangulated iso-surface. 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated @@ -725,11 +719,11 @@ dim: (k,)--> 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality that are not transformable into proxies or for which no transformation into proxies was instructed. - + 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. - + In the second step, the tool can be used to analyze the proximity of these objects to a model of the surface (edge) of the dataset. @@ -771,7 +765,7 @@ dim: (k,)--> - + The explicit identifier of features. @@ -784,7 +778,7 @@ dim: (k,)--> In all situations instances of the parent NXprocess group are returned with a very similar information structuring and thus we here replace the template name FEATURE with one of the following types feature-specific group names: - + * objects, objects, irrespective their distance to the surface * objects_close_to_edge, sub-set of v_feature_object close surface * objects_far_from_edge, sub-set of v_feature_object not close to the surface @@ -792,9 +786,9 @@ dim: (k,)--> * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - + - Explicit identifier of the feature a sub-set of the identifier_feature in the + Explicit identifier of the feature a sub-set of the indices_feature in the parent group. @@ -856,12 +850,12 @@ dim: (k,)--> - + - + @@ -873,17 +867,13 @@ MK::namely k != i each OBB has eight vertices--> Instances should use object as a name prefix. - - + @@ -895,19 +885,19 @@ identifier_face_offset(NX_UINT):--> - + - + - + - Array of identifier_evaporation / identifier_ion which details which ions + Array of evaporation_id / identifier_ion which details which ions lie inside or on the surface of the feature. @@ -999,7 +989,7 @@ identifier_face_offset(NX_UINT):--> The triangle surface mesh representing the interface model. Exported at state before or after the next DCOM step. - + Instances should use mesh_state as a name prefix. @@ -1011,17 +1001,17 @@ identifier_face_offset(NX_UINT):--> - - - + + + - - - - - - - + + + + + + + @@ -1045,7 +1035,7 @@ identifier_face_offset(NX_UINT):--> Qualifier which details how specifically oriented the face normal is with respect to its primitive (triangle): - + * 0 - undefined * 1 - outer * 2 - inner @@ -1054,7 +1044,7 @@ identifier_face_offset(NX_UINT):--> - + @@ -1073,7 +1063,7 @@ identifier_face_offset(NX_UINT):--> Qualifier which details how specifically oriented the face normal is with respect to its primitive (triangle): - + * 0 - undefined * 1 - outer * 2 - inner @@ -1131,8 +1121,8 @@ identifier_face_offset(NX_UINT):--> resolves the lateral surface of each cylinder such that their renditions are smooth in visualization software like Paraview. - - + + Position of the geometric center, which often is but not @@ -1154,7 +1144,7 @@ identifier_face_offset(NX_UINT):--> - + XDMF support to enable coloring each ROI by its identifier. @@ -1243,9 +1233,9 @@ identifier_face_offset(NX_UINT):--> - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index bf564c9705..30e0e1ecbf 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -40,7 +40,7 @@ Application definition for a configuration file of the paraprobe-ranger tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -74,7 +74,7 @@ - + @@ -82,7 +82,7 @@ - + @@ -90,7 +90,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 886e895ccb..eb6ad19d97 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -34,7 +34,7 @@ Application definition for results files of the paraprobe-ranger tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within a certain (possibly complicated) selection of ions (based on their properties or location in the @@ -55,8 +55,6 @@ ion is considered of the default *unknown_type*. This iontype is marked with a 0 in the iontypes array. - @@ -103,9 +101,9 @@ config--> - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 3a051b91ee..55c25e1431 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -29,7 +29,7 @@ Application definition for a configuration file of the paraprobe-selector tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -62,7 +62,7 @@ - + @@ -70,7 +70,7 @@ - + @@ -78,7 +78,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index faf31fa38a..9937928945 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -34,7 +34,7 @@ Application definition for results files of the paraprobe-selector tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). @@ -75,9 +75,9 @@ - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index ea843db0e9..44053f3209 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -44,7 +44,7 @@ Application definition for a configuration file of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -94,10 +94,10 @@ of the dataset so that the ion can act as a source. This means that an ROI is placed at the location of the ion and its neighbors are analyzed how they contribute to the computed statistics. - + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a microstructural feature an ROI is placed. - + The threshold is useful to process the dataset such that ROIs do not protrude out of the dataset as this would add bias. @@ -127,7 +127,7 @@ 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 this feature_distance threshold is used in combination with the edge_distance threshold when placing ROI about source ions. @@ -138,7 +138,7 @@ - + @@ -146,7 +146,7 @@ - + @@ -154,7 +154,7 @@ - + @@ -205,25 +205,25 @@ identifier(NX_UINT):--> 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 diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index e1e315dd36..b21ba6c8e1 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -44,7 +44,7 @@ Application definition for results files of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -70,7 +70,7 @@ 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 remain the same. - + The order matches the iontypes array from a given ranging results as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. @@ -167,9 +167,9 @@ - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index 0a46542c87..994310a8ec 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -39,7 +39,7 @@ Application definition for a configuration file of the paraprobe-surfacer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -72,7 +72,7 @@ - + @@ -80,7 +80,7 @@ - + @@ -88,7 +88,7 @@ - + @@ -120,8 +120,8 @@ Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. - + prior to the alpha-shape computation. + The option *default* specifies that no such filtering is applied. The option *kuehbach* specifies that a Hoshen-Kopelman percolation analysis is used to identify points that lie closer @@ -144,26 +144,26 @@ Specifies which method to use to define the alpha value. - + The value *convex_hull_naive* is the default. The setting 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* instructs to tool to refine the quality of the mesh resulting from *convex_hull_naive* via triangle flipping and splitting. - + 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 CGAL library to choose a value which the library considers as to be an optimal value. Details are defined in the respective section of the CGAL library on 3D alpha shapes. - + The value *set_of_values* instructs the tool to compute a list collection of alpha-shapes for the specified alpha-values. - + The value *set_of_alpha_wrappings* instructs the tool to generate a set of so-called alpha wrappings. These are similar to alpha-shapes but provide additional guarantees (such as watertightness and @@ -180,7 +180,7 @@ - Array of alpha values to use when alpha_value_choice is + Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index eca920007c..98ff985bc0 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -54,7 +54,7 @@ Application definition for results files of the paraprobe-surfacer tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-surfacer tool is the generation of meshed representation of the surface of the the reconstructed volume (or a portion) of it @@ -75,11 +75,11 @@ 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. @@ -102,7 +102,7 @@ for eventually performed preprocessing--> A bitmask which identifies exactly all those ions whose positions were considered when defining the filtered point set from which that alpha_complex instance was computed. - + This window can be different to the window of the *point_set_wrapping* parent group because irrelevant ions might have been filtered out in addition to the window defined in *point_set_wrapping* to reduce e.g. computational @@ -129,7 +129,7 @@ for eventually performed preprocessing--> - + @@ -157,20 +157,20 @@ for eventually performed preprocessing--> The set of triangles in the coordinate system paraprobe which discretizes the exterior surface of the alpha complex. - + - - - - + + + + - + @@ -204,17 +204,17 @@ for eventually performed preprocessing--> The set of tetrahedra which represent the interior volume of the complex if that is a closed two-manifold. - + The accumulated volume of all interior tetrahedra. - - - - + + + + @@ -256,9 +256,9 @@ For the future as we may wish to wrap primitives other like triangles or polylin - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index bebe5dc886..cf1136e8f6 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -30,7 +30,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin Application definition for a configuration file of the paraprobe-tessellator tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -41,7 +41,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + @@ -69,7 +69,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + @@ -77,7 +77,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + @@ -85,7 +85,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index d9c8ed20f6..faca2730a6 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -45,7 +45,7 @@ Application definition for results files of the paraprobe-tessellator tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -97,12 +97,12 @@ - + - + The number of points (and thus cells). @@ -115,7 +115,7 @@ - + Which MPI process computed which Voronoi cell. @@ -123,7 +123,7 @@ - + Which OpenMP thread computed which Voronoi cell. @@ -131,7 +131,7 @@ - + The number of faces for each cell. Faces of adjoining polyhedra are counted for each polyhedron. This field can be used to interpret the concatenated vector @@ -141,16 +141,16 @@ - + A simple approach to describe the entire set of polyhedra when the main intention is to store the shape of the polyhedra for visualization purposes. - - - - + + + + @@ -159,14 +159,14 @@ Each tuple contains encodes information to visualize using XDMF: Firstly, an XDMF geometric primitive type key. Secondly, the number of vertices of the polygon. - Third, the sequence of identifier_vertex which define the facet. + Third, the sequence of indices_vertex which define the facet. Tuples encode faces faster than cells. - + Sequence of cell identifier, concatenated such that each face is associated with its cell. Given that paraprobe-tessellator assigns @@ -301,9 +301,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index c70b7b9d35..56d549b7a4 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -24,21 +24,21 @@ Base class documenting the information common to tools of the paraprobe-toolbox. - + The paraprobe-toolbox is a collection of open-source tools for performing efficient analyses of point cloud data where each point can represent atoms or (molecular) ions. A key application of the toolbox has been for research in the field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - + The toolbox does not replace but complements existent software tools in this research field. Given its capabilities of handling points as objects with properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - + The common section can be used as a place to store e.g. organizational metadata and contextualization of that analysis in a research data management system. @@ -49,7 +49,7 @@ or whether this failed. Status is written to the results file after the end_time beyond which point in time the tool must no longer compute any further analysis results but exit. - + Only when this status message is present and its value is `success`, one should consider the results of the tool. In all other cases it might be that the tool has terminated prematurely or another error occurred. @@ -60,7 +60,7 @@ - + Internal identifier used by the tool to refer to an analysis (aka simulation id). @@ -104,7 +104,7 @@ 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: - + * paraprobe * lab * specimen @@ -112,7 +112,7 @@ * 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 diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index b02983e163..79eb264db0 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -24,21 +24,21 @@ Base class documenting the configuration used for a tool of the paraprobe-toolbox. - + The paraprobe-toolbox is a collection of open-source software tools for performing efficient analyses of point cloud data where each point can represent atoms or (molecular) ions. A key application of the toolbox has been for research in the field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - + The toolbox does not replace but complements existent software tools in this research field. Given its capabilities of handling points as objects with properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - + The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). @@ -53,7 +53,7 @@ Possibility for leaving a free-text description about this analysis. - + Although offered here for convenience we strongly encourage to parameterize such descriptions as much as possible to support reusage and clearer communication. @@ -64,7 +64,7 @@ base class from which tool-specific application definitions inherit--> Specification of the tomographic reconstruction to use for this analysis. - + Typically, reconstructions in the field of atom probe tomography are communicated via files which store at least reconstructed ion positions and mass-to-charge-state-ratio values. Container files like HDF5 though can store multiple reconstructions. @@ -87,12 +87,12 @@ base class from which tool-specific application definitions inherit--> Specification of the ranging definitions to use for this analysis. - + Ranging is the process of labeling time-of-flight data with so-called iontypes (aka ion species). Ideally, iontypes specify the most likely (molecular) ion that is assumed to have been evaporated given that its mass-to-charge-state ratio lies within the specific mass-to-charge-state-ratio value interval of the iontype. - + The so-called UNKNOWNTYPE iontype represents the null model of an ion that has not been ranged (for whatever reasons). The identifier of this special iontype is always the reserved value 0. @@ -107,7 +107,7 @@ base class from which tool-specific application definitions inherit--> Specification of the triangulated surface mesh to use for this analysis. - + Such a surface mesh can be used to define the edge of the reconstructed volume to account for finite size effects. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 6cb0917fa8..2b5aeece09 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -52,25 +52,25 @@ i be careful n_comb can vary for every instance of (NXion) !--> Application definition for results files of the paraprobe-transcoder tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to exchange information especially when it comes to the communication of configurations and results from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document their origin and thus the sequence in which the file was generated during an analysis. - + Paraprobe-transcoder solves this limitation by interpreting the information content in such files and standardize the representation prior injection into the scientific data analysis tools of the toolbox. Therefore, the here proposed set of NeXus base classes and application definitions can be a useful starting point for the atom probe community to take advantage of standardized information exchange and improve the here proposed classes and concepts to become more inclusive. - + Paraprobe-transcoder uses a Python library developed based on efforts by members of the global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the actual low-level I/O operations and respective information interpretation of above-mentioned file formats. @@ -183,9 +183,9 @@ config--> - - - + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccebfc8c05..1b1134c368 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -56,26 +56,26 @@ duplicate of an NXoff_geometry ?--> Computational geometry of primitives via a face-and-edge-list data structure. - + Primitives must neither be degenerated nor self-intersect but can have different properties. A face-and-edge-list-based description of primitives is frequently used for triangles and polyhedra to store them on disk for visualization purposes (see OFF, PLY, VTK, or STL file formats). - + Although this description is storage efficient, it is not well-suited for topological analyses. In this case using a half-edge data structure is - an alternative. - + an alternative. + Having an own base class for the data structure how primitives are stored is useful to embrace both users with small or detailed specification demands. - + Indices can be used as identifier and thus names for individual instances. - + Number of vertices for each face. - + Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. @@ -83,10 +83,10 @@ duplicate of an NXoff_geometry ?--> - + Number of edges for each face. - + Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> - + Number of faces of the primitives. @@ -103,7 +103,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the vertices differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -112,7 +112,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the edges differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -121,7 +121,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the faces differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Positions of the vertices. - + Users are encouraged to reduce the vertices to a unique set as this may result in more efficient storage. Alternatively, storing vertex positions naively should be indicated with setting vertices_are_unique to False. @@ -177,12 +177,12 @@ duplicate of an NXoff_geometry ?--> The faces are stored as a concatenated array of vertex identifier tuples. - + 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> If true, indicates that no edge is stored more than once. - + Users are encouraged to consider using a half_edge_data_structure instead. @@ -214,7 +214,7 @@ duplicate of an NXoff_geometry ?--> 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_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index abff32b117..00ea6f1a71 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -44,7 +44,7 @@ Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - + Three-dimensional grids with cubic cells are if not the most frequently used example of such grids. Numerical methods and models that use grids are used in many cases in the natural sciences and engineering disciplines. Examples are @@ -54,7 +54,7 @@ Location of the origin of the grid. - + Use the depends_on field that is inherited from the :ref:`NXcg_primitive` class to specify the coordinate system in which the origin location is defined. @@ -81,7 +81,7 @@ 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 @@ -121,10 +121,10 @@ should constraints on the grid be place here or not--> - + Number of boundaries distinguished - + Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. @@ -141,7 +141,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele The boundary conditions for each boundary: - + 0 - undefined 1 - open 2 - periodic @@ -158,17 +158,17 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Details about the computational geometry method and implementation used for discretizing internal surfaces as e.g. obtained with marching methods, like marching squares or marching cubes. - + Documenting which specific version was used helps with understanding how robust the results are with respect to the topology of the triangulation. 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 ideally be an identifier of a program. If not possible, an identifier for a paper, technical report, or free-text description can be used instead. diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index cf36b73d98..db7a88818d 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -50,11 +50,11 @@ Computational geometry 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. The data structure is also known as a doubly connected edge list. - + Indices can be used as identifier and thus names for individual instances. @@ -63,10 +63,10 @@ - + Number of vertices for each face. - + Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. @@ -74,10 +74,10 @@ - + Number of edges for each face. - + Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. @@ -89,7 +89,7 @@ Integer offset whereby the identifier of the first member of the vertices differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -98,7 +98,7 @@ Integer offset whereby the identifier of the first member of the edges differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -107,7 +107,7 @@ Integer offset whereby the identifier of the first member of the faces differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -183,11 +183,11 @@ 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_polygon.nxdl.xml b/contributed_definitions/NXcg_polygon.nxdl.xml index 7cb6cb5739..7c88a41589 100644 --- a/contributed_definitions/NXcg_polygon.nxdl.xml +++ b/contributed_definitions/NXcg_polygon.nxdl.xml @@ -46,30 +46,30 @@ Computational geometry description of a set of polygons in Euclidean space. - + Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed polyhedra. Even more general complexes can be thought of. An example are the so-called piecewise-linear complexes used in the TetGen library. - + As these complexes 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 to describe such even more complex primitives instead of abusing this base class for such purposes. - + The total number of vertices in the set. @@ -83,14 +83,14 @@ Individual storage of the mesh of each polygon. - + Instances should use polygon as a name prefix. Individual storage of each polygon as a graph. - + Instances should use polygon_half_edge as a name prefix. @@ -118,7 +118,7 @@ Curvature type: - + * 0 - unspecified, * 1 - convex, * 2 - concave diff --git a/contributed_definitions/NXcg_polyhedron.nxdl.xml b/contributed_definitions/NXcg_polyhedron.nxdl.xml index 1a304a31ea..257472e3b6 100644 --- a/contributed_definitions/NXcg_polyhedron.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron.nxdl.xml @@ -54,17 +54,17 @@ for clean graph-based descriptions of polyhedra.--> Computational geometry description of a set of polyhedra in Euclidean space. - + Polyhedra or so-called cells (especially in the convex of tessellations) are constructed from polygon meshes. Polyhedra may make contact to allow a usage of this base class for a description of tessellations. - + For the description of more complicated manifolds and especially for polyhedra with holes, users are advised to check if their particular needs are described by creating customized instances of an :ref:`NXcg_polygon`. - + The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. @@ -81,7 +81,7 @@ for clean graph-based descriptions of polyhedra.--> - + The number of edges for each polyhedron. Edges of adjoining polyhedra are counted for each polyhedron. @@ -104,14 +104,14 @@ for clean graph-based descriptions of polyhedra.--> Individual storage of each polyhedron. - + Instances should use polyhedron as a name prefix. Individual storage of each polygon as a graph. - + Instances should use cluster_analysis as a name prefix. diff --git a/contributed_definitions/NXcg_polyline.nxdl.xml b/contributed_definitions/NXcg_polyline.nxdl.xml index 50fec5fdc5..6ecc901fb8 100644 --- a/contributed_definitions/NXcg_polyline.nxdl.xml +++ b/contributed_definitions/NXcg_polyline.nxdl.xml @@ -51,7 +51,7 @@ multiple vertices possible with the same point coordinates but different names.- Computational geometry description of a set of polylines. - + 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 traversal along the polyline when @@ -64,17 +64,17 @@ multiple vertices possible with the same point coordinates but different names.- NXcg_polyline instance. - + The total number of vertices that have different positions. - + The total number of vertices, irrespective of their eventual uniqueness. - + The total number of vertices of each polyline, irrespectively whether vertices are shared by vertices or not. @@ -90,7 +90,7 @@ they share the same position in space but have different identifiers.--> Positions of the vertices which support the members of the polyline set. - + Users are encouraged to reduce the vertices to unique positions and vertices as this often supports with storing geometry data more efficiently. It is also possible though to store the vertex positions naively @@ -114,22 +114,22 @@ they share the same position in space but have different identifiers.--> Sequence of identifier for vertices how they build each polyline. - + A trivial example is a set with two polylines with three vertices each. If the polylines meet at a vertex (assume for example that the second vertex is shared and marking the junction between the two polylines), it is possible that there are only five unique positions. This suggests to store five unique vertices. - + A non-trivial example is a set with several polylines. Assume that each has a different number of vertices. The array stores the identifier of the vertices in the sequence how the polylines are visited: - + The first entry is the identifier of the first vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex of the first polyline. Thereafter, the first vertex of the second polyline, and so on and so forth. - Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), + Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), the vertices of the N-th polyline can be accessed on the array index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 23717c288d..da136e2920 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -2,9 +2,9 @@ diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index 6756ad8df0..cf4ff1883c 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -53,9 +53,9 @@ are aligned with what and how to name things--> Application definition for minimal example in-situ calorimetry. - + TODO: - + * What is the technique about. * General context. * Literature references. @@ -107,7 +107,7 @@ are aligned with what and how to name things--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources. @@ -121,7 +121,7 @@ are aligned with what and how to name things--> Reference to the resource which stores acquired pattern from the experiment or simulation that are analyzed in this workflow. - + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. @@ -157,14 +157,14 @@ are aligned with what and how to name things--> with which delta_time can be converted in timestamp. The reference timestamp is defined as the time when the actuator started acting on the sample. - + Time differences to this timestamp when correlated signals such as diffraction pattern matching with a specific state of the sample (e.g. obtained temperature via the actuator) are reported through delta_time. - + @@ -172,7 +172,7 @@ are aligned with what and how to name things--> Time difference to start_time. - + Collecting diffraction pattern also takes some time. It is assumed that the acquisition time for each pattern is substantial shorter than the time it takes the actuator to @@ -239,7 +239,7 @@ NXcg_ellipsoid--> The integrated intensities: - + * result_with_background * result_without_background @@ -258,7 +258,7 @@ NXcg_ellipsoid--> - + Identifier for each pattern. diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index 9767e5951a..127e776f05 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -42,12 +42,12 @@ Application definition for the configuration of the legacy (micro)structure generator developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. @@ -65,7 +65,7 @@ discretized into material points using either square pixel or cubic voxel as the tessellating unit cells. - + Two-dimensional or three-dimensional simulation. diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 59e35a363e..02c52005fc 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -72,7 +72,7 @@ Application definition to configure a simulation with the SCORE model. - + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ @@ -103,7 +103,7 @@ exists: optional--> - + Dimensionality of the simulation. @@ -126,7 +126,7 @@ exists: optional--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from other sources. @@ -185,7 +185,7 @@ SecondOrderThermalExpCoeff--> Which model should be used to generate a starting microstructure. - + * cuboidal, a regular array of equally shaped cuboidal grains * poisson_voronoi, a discretized poisson voronoi * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map @@ -288,7 +288,7 @@ SecondOrderThermalExpCoeff--> According to which model will the nuclei become distributed spatially: - + * csr, complete spatial randomness * custom, implementation-specific * gb, nuclei placed at grain boundaries @@ -309,7 +309,7 @@ SecondOrderThermalExpCoeff--> According to which model will the nuclei get their orientation assigned: - + * ensemble, picking randomly one from ensemble/bunge_euler * random, picking randomly on the SO3 * damask, picking based on information provided in deformation/damask @@ -355,7 +355,7 @@ SecondOrderThermalExpCoeff--> Which type of fundamental model for the grain boundary mobility. - + Grain boundaries with disorientation angle smaller than 15 degree are considered as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. @@ -655,7 +655,7 @@ like showing a r(t) plot--> with up to :math:`1600^3` cells. Snapshot data document the current microstructure including the assignment of grains and cells surplus the state of the recrystallization front. - + Despite these front data make up for approximately one order of magnitude less cells than represented in the domain, more numerical data have to be collected for each cell in the front than just a grain identifier. diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 4df1f58553..90c554cc19 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -72,15 +72,15 @@ inspect comments behind NXmicrostructure--> Application definition for storing results of the SCORE cellular automata model. - + The SCORE cellular automata model for primary recrystallization is an example of a typical materials engineering application 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 nuclei during static recrystallization. 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>`_ @@ -211,7 +211,7 @@ inspect comments behind NXmicrostructure--> - + How many distinct boundaries are distinguished? Most grids discretize a cubic or cuboidal region. In this case @@ -221,7 +221,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele The boundary conditions for each boundary: - + * 0 - undefined * 1 - open * 2 - periodic @@ -247,18 +247,18 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Documentation of the spatiotemporal evolution for each CA domain. - + SCORE is a hybrid parallelized code that can evolve multiple replicas in parallel. The set of replicas is distributed across MPI processes. Each such replica is then evolved via OpenMP multi-threading. - + Instances should use spatiotemporal as a name prefix. Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening for practical and performance reasons + (averaging, integrating, interpolating) happening for practical and performance reasons during the simulation. Place used for storing descriptors from continuum mechanics and thermodynamics at the scale of the entire ROI. @@ -409,7 +409,7 @@ the typically storage-costlier snapshot data--> - + Index for each crystal whereby its metadata can be retrieved. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 386f253c9d..72601c6e7d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -49,18 +49,18 @@ Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - + Similarity grouping algorithms are segmentation or machine learning algorithms for partitioning the members of a set of objects (e.g. geometric primitives) into (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - + This base class considers metadata and results of having a similarity grouping algorithm applied to a set in which objects are either categorized as noise or belonging to a cluster, i.e. members of a cluster. The algorithm assigns each similarity group (feature/cluster) at least one identifier (numerical or categorical labels) to distinguish different cluster. - + Number of members in the set which gets partitioned into features. @@ -84,7 +84,7 @@ results for the object set--> Which numerical index is the first to be used to label a feature. - + The value should be chosen in such a way that special values can be resolved: * index_offset - 1 indicates that an object belongs to no cluster. * index_offset - 2 indicates that an object belongs to the noise category. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index f99b44117e..46ca0ef407 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -850,11 +850,19 @@ NXapm(NXobject): unit: NX_UNITLESS doc: | CRunHeader.fTotalEventRecords - hit_quality(NX_UINT): + hit_quality_type(NX_CHAR): exists: optional doc: | - Identifier used for each hit_quality type. - Following the order of hit_quality_types. + Hit quality is an integer that specifies which category/type a hit was assigned to. + This field lists the human-readable, possibly though proprietary types distinguished. + The indices of this array are used in hit_quality to encode hit_quality for each + pulse in a more efficient way than by repeating the string that is used for each + type as it is provided in this field. + + As an example assume two types golden and partial are distinguished. + If hit_quality_type stores the array "golden", "partial", the index 0 + in hit_quality identifies all those pulses of category golden, + while the index 1 in hit_quality identifies all of category partial. dimensions: rank: 1 dim: (n_ht,) @@ -1237,7 +1245,7 @@ NXapm(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f2f0508164f79388e8c66c86b55e043e8a251b445c02d5c508b0ed122ac8a1d0 +# aea11bb9aa74ed5e31c1738b97420a496268f2571756bc53119e74cc2b082014 # # # -# +# # # For each ion, the identifier of the voxel into which the ion binned. # @@ -617,7 +613,7 @@ NXapm_compositionspace_results(NXobject): # # # Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. -# +# # Instances should use cluster_analysis as a name prefix. # # @@ -694,7 +690,7 @@ NXapm_compositionspace_results(NXobject): # # The maximum distance between voxel pairs in a neighborhood # to be considered connected. -# +# # Instances should use dbscan as a name prefix. # # @@ -715,7 +711,7 @@ NXapm_compositionspace_results(NXobject): # # # Voxel identifier -# +# # Using these identifiers correlated element-wise with the values in the label array # specifies for which voxel in the grid clusters from this process were found. # @@ -734,7 +730,4 @@ NXapm_compositionspace_results(NXobject): # # # -# # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 0e973c29c5..260bf3e29a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -104,14 +104,14 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -119,7 +119,7 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -132,10 +132,6 @@ NXapm_paraprobe_clusterer_config(NXobject): number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -317,7 +313,7 @@ NXapm_paraprobe_clusterer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f986e00c983c27fa7f7121a25902d457ce5ef89a366de044e4141f68a3f268f1 +# d03710e6b442eac4b69a38a86f9a82157658d23a31610dfeba414aa5c1e686e6 # # # # # # @@ -513,28 +506,28 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # How should iontypes be considered during the cluster analysis. -# +# # 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 nuclide structure. -# +# # The value resolve_element will set an ion active and account as many times # for it, as the (molecular) ion contains atoms of elements in the whitelist # ion_query_nuclide_vector. -# +# # The value resolve_isotope will set an ion active and account as many times # for it, as the (molecular) ion contains nuclides in the whitelist # ion_query_nuclide_vector. -# +# # In effect, ion_query_nuclide_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 an ion of a molecular # ion with more than one nuclide, say Ti O for example is counted potentially several # times because at that position (reconstructed) position it has been assumed that @@ -563,10 +556,10 @@ NXapm_paraprobe_clusterer_config(NXobject): # # Settings for DBScan clustering algorithm. For original details about the # algorithm 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>`_ @@ -574,16 +567,16 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # Strategy how a set of cluster analyses with different parameter is executed: -# +# # * For tuple as many runs are performed as parameter values have been defined. # * For combinatorics individual parameter arrays are looped over. -# +# # As an example we may provide ten entries for eps and three entries for min_pts. # If high_throughput_method is set to tuple, the analysis is invalid because we have # an insufficient number of min_pts values to pair them with our ten eps values. # By contrast, if high_throughput_method is set to combinatorics, the tool will run three # individual min_pts runs for each eps value, resulting in a total of 30 analyses. -# +# # A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ # can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), # one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. @@ -634,10 +627,10 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # 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. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index d9f46e7df3..d98ad093ad 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -50,28 +50,29 @@ NXapm_paraprobe_clusterer_results(NXobject): unit: NX_UNITLESS doc: | The minimum points (min_pts) parameter used. - cardinality(NX_UINT): + cardinality(NX_POSINT): unit: NX_UNITLESS doc: | Number of members in the set which is partitioned into features. Specifically, this is the total number of targets filtered from the dataset, i.e. typically the number of clusters which is usually not and for sure not necessarily the total number of ions in the dataset. - identifier_offset(NX_INT): + index_offset(NX_INT): + unit: NX_UNITLESS 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. + * index_offset - 1 indicates an object belongs to no cluster. + * index_offset - 2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used + Setting for instance index_offset to 1 recovers the commonly used case that objects of the noise category get the value of -1 and points of the unassigned category get the value 0. targets(NX_UINT): unit: NX_UNITLESS doc: | - The evaporation (sequence) identifier (aka identifier_evaporation) to figure out + The evaporation (sequence) id (aka evaporation_id) to figure out which ions from the reconstruction were considered targets. The length of this array is not necessarily n_ions. Instead, it is the value of cardinality. @@ -142,10 +143,6 @@ NXapm_paraprobe_clusterer_results(NXobject): dimensions: rank: 1 dim: (k,) - - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): is_noise(NX_BOOLEAN): exists: optional doc: | @@ -153,10 +150,6 @@ NXapm_paraprobe_clusterer_results(NXobject): dimensions: rank: 1 dim: (k,) - - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): is_core(NX_BOOLEAN): exists: optional doc: | @@ -173,14 +166,15 @@ NXapm_paraprobe_clusterer_results(NXobject): # at the level of the set of targets number_of_targets(NX_UINT): + unit: NX_UNITLESS doc: | Total number of targets in the set, i.e. ions that were filtered and considered in this cluster analysis. - number_of_noise(NX_UINT): + number_of_noise_members(NX_UINT): unit: NX_UNITLESS doc: | Total number of members in the set which are categorized as noise. - number_of_core(NX_UINT): + number_of_core_members(NX_UINT): unit: NX_UNITLESS doc: | Total number of members in the set which are categorized as a core point. @@ -190,14 +184,14 @@ NXapm_paraprobe_clusterer_results(NXobject): Total number of clusters (excluding noise and unassigned). # at the level of the feature set - identifier_feature(NX_UINT): + indices_feature(NX_INT): unit: NX_UNITLESS doc: | - Numerical identifier of each feature aka identifier_cluster. + Numerical identifier of each feature aka cluster_id. dimensions: rank: 1 dim: (n_feat,) - feature_member_count(NX_UINT): + number_of_members(NX_UINT): unit: NX_UNITLESS doc: | Number of members for each feature. @@ -218,9 +212,9 @@ NXapm_paraprobe_clusterer_results(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + number_of_processes(NX_UINT): + number_of_threads(NX_UINT): + number_of_gpus(NX_UINT): (NXuser): exists: ['min', '0', 'max', 'unbounded'] doc: | @@ -248,7 +242,7 @@ NXapm_paraprobe_clusterer_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0f3236fc7f667546b711f80a9e964b3f8ada5ef723619dde316e539efd4fabdb +# aa11faba17a56d3b4be4322780e2f2f940d154dcd340b4fcdb925d74cc558ad8 # # # # # # Are targets assigned to the noise category or not. @@ -442,11 +431,6 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# # # # Are targets assumed a core point. @@ -462,18 +446,18 @@ NXapm_paraprobe_clusterer_results(NXobject): # cluster were found. # # -# +# # # Total number of targets in the set, i.e. ions that were filtered # and considered in this cluster analysis. # # -# +# # # 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. # @@ -484,15 +468,15 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# +# # -# Numerical identifier of each feature aka identifier_cluster. +# Numerical identifier of each feature aka cluster_id. # # # # # -# +# # # Number of members for each feature. # @@ -516,9 +500,9 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# -# -# +# +# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 4b7d52752d..b6d48383f1 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -38,14 +38,14 @@ NXapm_paraprobe_distancer_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -53,7 +53,7 @@ NXapm_paraprobe_distancer_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -67,9 +67,7 @@ NXapm_paraprobe_distancer_config(NXobject): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): + # evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -113,9 +111,9 @@ NXapm_paraprobe_distancer_config(NXobject): Each triangle_set that is referred to here should be a face_list_data_structure, i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - + Instances should use triangle_set as a name prefix. type(NX_CHAR): algorithm(NX_CHAR): @@ -139,7 +137,7 @@ NXapm_paraprobe_distancer_config(NXobject): doc: | Absolute path in the (HDF5) file that points to the array of facet normal vectors for the triangles in that triangle_set. - identifier_patch(NX_CHAR): + indices_patch(NX_CHAR): exists: optional doc: | Absolute path in the (HDF5) file that points to the array @@ -164,7 +162,7 @@ NXapm_paraprobe_distancer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 156d418f0810f31078f74822927ab70cbc2bbc8b2d0bf91bb2d29c2a0eb828af +# 200950d379de89698f4f6e3cc83c5bf15af90e0f7b15a92dc9bdeaf85762d91b # # # -# +# # # # @@ -276,7 +272,7 @@ NXapm_paraprobe_distancer_config(NXobject): # # # Specifies for which point the tool will compute distances. -# +# # The value *default* configures that distances are computed for all points. # The value *skin* configures that distances are computed only for those # points which are not farther away located to a triangle than @@ -306,9 +302,9 @@ NXapm_paraprobe_distancer_config(NXobject): # Each triangle_set that is referred to here should be a face_list_data_structure, # i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) # array of NX_UINT incident vertices of each facet. Vertex indices are assumed to -# start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. +# start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. # Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. -# +# # Instances should use triangle_set as a name prefix. # # @@ -339,7 +335,7 @@ NXapm_paraprobe_distancer_config(NXobject): # of facet normal vectors for the triangles in that triangle_set. # # -# +# # # Absolute path in the (HDF5) file that points to the array # of identifier for the triangles in that triangle_set. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 6836186551..bbd51e97a0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -52,16 +52,16 @@ NXapm_paraprobe_distancer_results(NXobject): dimensions: rank: 1 dim: (n_ions,) - identifier_triangle(NX_UINT): + indices_triangle(NX_INT): exists: optional unit: NX_UNITLESS doc: | For each point the identifier of the triangle for which the - shortest distance was found + shortest distance was found. dimensions: rank: 1 dim: (n_ions,) - identifier_point(NX_UINT): + indices_point(NX_INT): exists: optional unit: NX_UNITLESS doc: | @@ -128,9 +128,9 @@ NXapm_paraprobe_distancer_results(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + number_of_processes(NX_UINT): + number_of_threads(NX_UINT): + number_of_gpus(NX_UINT): (NXuser): exists: ['min', '0', 'max', 'unbounded'] doc: | @@ -158,7 +158,7 @@ NXapm_paraprobe_distancer_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 215366866eee513ec55b3569917e5355f9b9cb96cfbbb1042d9f6087c368a7cc +# dd19c39460ee00e71df643b973731be56829f99741ceee5f79c9b03f2f147906 # # # @@ -279,14 +279,14 @@ NXapm_paraprobe_intersector_config(NXobject): # 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>`_, # it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron # intersections in paraprobe-intersector. @@ -340,7 +340,7 @@ NXapm_paraprobe_intersector_config(NXobject): # 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 can be interpreted as the time/iteration (i.e. :math:`k`) # step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). @@ -392,7 +392,7 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# +# # # Array of identifier whereby the path to the geometry data can be inferred # automatically. @@ -410,7 +410,7 @@ NXapm_paraprobe_intersector_config(NXobject): # 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 current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) # step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). @@ -457,7 +457,7 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# +# # # Array of identifier whereby the path to the geometry data can be inferred # automatically. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index a0a9916484..1fa3e15a18 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -36,7 +36,7 @@ NXapm_paraprobe_intersector_results(NXobject): current_to_next_link(NX_UINT): unit: NX_UNITLESS doc: | - A matrix of identifier_feature that specifies which named features + A matrix of indices_feature that specifies which named features from the current_set have directed link(s) pointing to which named feature(s) from the next_set. dimensions: @@ -55,7 +55,7 @@ NXapm_paraprobe_intersector_results(NXobject): exists: optional unit: NX_UNITLESS doc: | - A matrix of identifier_feature which specifies which named feature(s) + A matrix of indices_feature 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 are defined is symmetric it holds that next_to_current maps @@ -95,7 +95,7 @@ NXapm_paraprobe_intersector_results(NXobject): The third comparison is the current_set against the next_set. Once the (forward) links for these comparisons are ready, pair relations - are analyzed with respect to which objects with identifier_feature + are analyzed with respect to which objects with indices_feature cluster in identifier space. Thereby, a logical connection (link) is established between the features in the current_set and the next_set. Recall that these two sets typically represent different features @@ -113,8 +113,8 @@ NXapm_paraprobe_intersector_results(NXobject): current_set_feature_to_cluster(NX_UINT): unit: NX_UNITLESS doc: | - Matrix of identifier_feature and identifier_cluster pairs which - encodes the cluster to which each identifier_feature was assigned. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. Here for features of the current_set. dimensions: rank: 2 @@ -122,13 +122,13 @@ NXapm_paraprobe_intersector_results(NXobject): next_set_feature_to_cluster(NX_UINT): unit: NX_UNITLESS doc: | - Matrix of identifier_feature and identifier_cluster pairs which - encodes the cluster to which each identifier_feature was assigned. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. Here for features of the next_set. dimensions: rank: 2 dim: (n_features_next, 2) - identifier_cluster(NX_UINT): + cluster_id(NX_UINT): unit: NX_UNITLESS doc: | The identifier (names) of the cluster. @@ -180,9 +180,9 @@ NXapm_paraprobe_intersector_results(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + number_of_processes(NX_UINT): + number_of_threads(NX_UINT): + number_of_gpus(NX_UINT): (NXuser): exists: ['min', '0', 'max', 'unbounded'] doc: | @@ -210,7 +210,7 @@ NXapm_paraprobe_intersector_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ae3964e8fb32d3c3ded86f695523c44b46639ee4a4f01528fe7b8d62a8f9579 +# 74f802b5eda5707493de0c5d4cf30d2e2e43a8cef7cfe50461d222e90cb414c4 # # # # # -# A matrix of identifier_feature that specifies which named features +# A matrix of indices_feature that specifies which named features # from the current_set have directed link(s) pointing to which named # feature(s) from the next_set. # @@ -311,7 +311,7 @@ NXapm_paraprobe_intersector_results(NXobject): # # # -# A matrix of identifier_feature which specifies which named feature(s) +# A matrix of indices_feature 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 are defined is symmetric it holds that next_to_current maps @@ -347,32 +347,32 @@ NXapm_paraprobe_intersector_results(NXobject): # 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, pair relations -# are analyzed with respect to which objects with identifier_feature +# are analyzed with respect to which objects with indices_feature # cluster in identifier space. Thereby, a logical connection (link) is # established between the features in the current_set and the next_set. # Recall that these two sets 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 for precipitates B. -# +# # Coprecipitation analysis now logically connects these independent # characterization results to establish spatial correlations of e.g. # the precipitates' spatial arrangement. # # # -# Matrix of identifier_feature and identifier_cluster pairs which -# encodes the cluster to which each identifier_feature was assigned. +# Matrix of indices_feature and cluster_id pairs which +# encodes the cluster to which each indices_feature was assigned. # Here for features of the current_set. # # @@ -382,8 +382,8 @@ NXapm_paraprobe_intersector_results(NXobject): # # # -# Matrix of identifier_feature and identifier_cluster pairs which -# encodes the cluster to which each identifier_feature was assigned. +# Matrix of indices_feature and cluster_id pairs which +# encodes the cluster to which each indices_feature was assigned. # Here for features of the next_set. # # @@ -391,7 +391,7 @@ NXapm_paraprobe_intersector_results(NXobject): # # # -# +# # # The identifier (names) of the cluster. # @@ -404,10 +404,10 @@ NXapm_paraprobe_intersector_results(NXobject): # 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 third column encodes the total number of members in the cluster. # # @@ -418,10 +418,10 @@ NXapm_paraprobe_intersector_results(NXobject): # # # 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. # @@ -451,9 +451,9 @@ NXapm_paraprobe_intersector_results(NXobject): # # # -# -# -# +# +# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 7a712677c1..aef7dc3fd9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -94,14 +94,14 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -109,7 +109,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -501,14 +501,14 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -516,7 +516,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -761,14 +761,14 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -776,7 +776,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -818,7 +818,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # dimensionality(NX_POSINT): # cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): dimensions: dim: (n_rois, 3) @@ -865,7 +865,7 @@ NXapm_paraprobe_nanochem_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 95a4157cdfb19b51ef5f05049aee77ec233f87b43d74fd9466432d05c1a1fdc4 +# 07560fef05d4614ba12d5556e7e60bc1c26975cb78d4fa6a8211d3991130c134 # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 43d21b5ce8..a6d4f8e839 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -66,10 +66,8 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | The discretized domain/grid on which the delocalization is applied. dimensionality(NX_POSINT): - unit: NX_UNITLESS enumeration: [1, 2, 3] cardinality(NX_POSINT): - unit: NX_UNITLESS doc: | The total number of cells/voxels of the grid. origin(NX_NUMBER): @@ -101,7 +99,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (d,) # coordinate_system implicit - identifier_offset(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing identifiers for cells. @@ -143,7 +141,7 @@ NXapm_paraprobe_nanochem_results(NXobject): is_axis_aligned(NX_BOOLEAN): doc: | For atom probe should be set to true. - identifier_offset(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing @@ -152,7 +150,7 @@ NXapm_paraprobe_nanochem_results(NXobject): :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. hexahedron(NXcg_face_list_data_structure): - vertex_identifier_offset(NX_INT): + vertex_index_offset(NX_INT): unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing @@ -160,7 +158,7 @@ NXapm_paraprobe_nanochem_results(NXobject): For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. - face_identifier_offset(NX_INT): + face_index_offset(NX_INT): unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing @@ -389,7 +387,7 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - + Instances should iso_surface as a name prefix. For applications in atom probe microscopy, the location and shape of such a boundary (set) @@ -414,15 +412,8 @@ NXapm_paraprobe_nanochem_results(NXobject): 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): - unit: NX_UNITLESS - 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 :math:`[identifier\_offset, identifier\_offset + c - 1]`. + index_offset(NX_INT): triangles(NXcg_face_list_data_structure): number_of_vertices(NX_POSINT): number_of_faces(NX_POSINT): @@ -642,7 +633,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensions: rank: 1 dim: (n_v_feat,) - identifier_feature(NX_UINT): + indices_feature(NX_INT): unit: NX_UNITLESS doc: | The explicit identifier of features. @@ -662,10 +653,10 @@ NXapm_paraprobe_nanochem_results(NXobject): * proxies, proxies, irrespective their distance to the surface * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - identifier_feature(NX_UINT): + indices_feature(NX_INT): unit: NX_UNITLESS doc: | - Explicit identifier of the feature a sub-set of the identifier_feature in the + Explicit identifier of the feature a sub-set of the indices_feature in the parent group. dimensions: rank: 1 @@ -721,12 +712,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # 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): + xdmf_topology(NX_INT): unit: NX_UNITLESS dimensions: rank: 1 dim: (k,) - identifier_feature_xdmf(NX_UINT): + indices_feature_xdmf(NX_INT): unit: NX_UNITLESS dimensions: rank: 1 @@ -737,18 +728,12 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | Instances should use object as a name prefix. polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # identifier_vertex_offset(NX_UINT): - # identifier_face_offset(NX_UINT): vertices(NX_FLOAT): unit: NX_LENGTH dimensions: rank: 2 dim: (n_v, 3) faces(NX_UINT): - unit: NX_UNITLESS dimensions: rank: 2 dim: (n_f, 3) @@ -757,23 +742,23 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensions: rank: 2 dim: (n_f, 3) - xdmf_topology(NX_UINT): + xdmf_topology(NX_INT): exists: recommended unit: NX_UNITLESS dimensions: rank: 1 dim: (k,) - identifier_feature_xdmf(NX_UINT): - exists: recommended + indices_feature_xdmf(NX_INT): unit: NX_UNITLESS + exists: recommended dimensions: rank: 1 dim: (k,) - identifier_ion(NX_UINT): + ion_id(NX_UINT): exists: optional unit: NX_UNITLESS doc: | - Array of identifier_evaporation / identifier_ion which details which ions + Array of evaporation_id / identifier_ion which details which ions lie inside or on the surface of the feature. dimensions: rank: 1 @@ -861,26 +846,16 @@ NXapm_paraprobe_nanochem_results(NXobject): Was this state exported before or after the next DCOM step. enumeration: [before, after] dimensionality(NX_POSINT): - unit: NX_UNITLESS cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS + index_offset(NX_INT): 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 - identifier_vertex_offset(NX_INT): - unit: NX_UNITLESS - identifier_edge_offset(NX_INT): - unit: NX_UNITLESS - identifier_face_offset(NX_INT): - unit: NX_UNITLESS - identifier_face(NX_UINT): - unit: NX_UNITLESS + number_of_vertices(NX_UINT): + number_of_faces(NX_UINT): + index_offset_vertex(NX_INT): + index_offset_edge(NX_INT): + index_offset_face(NX_INT): + indices_face(NX_INT): dimensions: rank: 1 dim: (j,) @@ -909,7 +884,6 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (i,) faces(NX_UINT): - unit: NX_UNITLESS dimensions: rank: 2 dim: (j, 3) @@ -976,9 +950,7 @@ NXapm_paraprobe_nanochem_results(NXobject): resolves the lateral surface of each cylinder such that their renditions are smooth in visualization software like Paraview. dimensionality(NX_POSINT): - unit: NX_UNITLESS cardinality(NX_POSINT): - unit: NX_UNITLESS center(NX_NUMBER): unit: NX_LENGTH doc: | @@ -997,7 +969,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (i, 3) # XDMF support - identifier(NX_UINT): + roi_id(NX_UINT): exists: optional unit: NX_UNITLESS doc: | @@ -1079,9 +1051,9 @@ NXapm_paraprobe_nanochem_results(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + number_of_processes(NX_UINT): + number_of_threads(NX_UINT): + number_of_gpus(NX_UINT): (NXuser): exists: ['min', '0', 'max', 'unbounded'] doc: | @@ -1109,7 +1081,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a0d301b2cab1f2815ae71b77a932d1bb68048bbb0a6645d5821f07728a9fa1e5 +# d950192a3b3217d1444ddddf207d1e840ca6743ca8f47143c52b04faf92e288c # # # -# +# # # 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 @@ -1344,7 +1316,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # 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. @@ -1354,7 +1326,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # Integer which specifies the first index to be used for distinguishing # identifiers for vertices. Identifiers are defined either implicitly or explicitly. @@ -1363,7 +1335,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # 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. @@ -1391,12 +1363,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -1436,7 +1408,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # The boundary conditions for each boundary: -# +# # 0 - undefined # 1 - open # 2 - periodic @@ -1455,10 +1427,10 @@ NXapm_paraprobe_nanochem_results(NXobject): # # The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces # will be computed. In commercial software so far there is no possibility to export this information. -# +# # If the intensity for all matches of the weighting_model are summarized name this NXdata instance # scalar_field_magn_total. -# +# # If the intensity is reported for each iontype one can avoid many subsequent # computations as individual intensities can be reinterpreted using a different weighting_model in # down-stream usage of the here reported values (e.g. with Python scripting). @@ -1614,12 +1586,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # An iso-surface is the boundary between two regions across which the magnitude of a # scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. -# +# # Instances should iso_surface as a name prefix. -# +# # For applications in atom probe microscopy, the location and shape of such a boundary (set) # is typically approximated by discretization - triangulation to be specific. -# +# # This yields a complex of not necessarily connected geometric primitives. # Paraprobe-nanochem approximates this complex with a soup of triangles. # @@ -1642,15 +1614,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # 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 :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# +# +# +# # # # @@ -1659,7 +1625,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # Positions of the vertices. -# +# # Users are encouraged to reduce the vertices to a unique set as this may # result in a more efficient storage of the geometry data. # It is also possible though to store the vertex positions naively in which @@ -1674,12 +1640,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -1712,7 +1678,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier how which specifically oriented normal to its # primitive each normal represents. -# +# # * 0 - undefined # * 1 - outer # * 2 - inner @@ -1738,7 +1704,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier how which specifically oriented normal to its # primitive each normal represents. -# +# # * 0 - undefined # * 1 - outer # * 2 - inner @@ -1826,9 +1792,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # This may yield a set of connected features whose individual surfaces are discretized # by a triangulated mesh each. Such volumetric features can be processed further using # paraprobe-nanochem using a workflow with at most two steps. -# +# # In the first step, the tool distinguishes three types of (v) i.e. volumetric features: -# +# # 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. # These objects were already watertight within the triangulated iso-surface. # 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated @@ -1837,11 +1803,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality # that are not transformable into proxies or for which no transformation into proxies was # instructed. -# +# # 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. -# +# # In the second step, the tool can be used to analyze the proximity of these objects to a # model of the surface (edge) of the dataset. # @@ -1883,7 +1849,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # The explicit identifier of features. # @@ -1896,7 +1862,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # In all situations instances of the parent NXprocess group are returned with a very similar # information structuring and thus we here replace the template name FEATURE # with one of the following types feature-specific group names: -# +# # * objects, objects, irrespective their distance to the surface # * objects_close_to_edge, sub-set of v_feature_object close surface # * objects_far_from_edge, sub-set of v_feature_object not close to the surface @@ -1904,9 +1870,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface # * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface # -# +# # -# Explicit identifier of the feature a sub-set of the identifier_feature in the +# Explicit identifier of the feature a sub-set of the indices_feature in the # parent group. # # @@ -1968,12 +1934,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # -# +# # # # # -# +# # # # @@ -1985,17 +1951,13 @@ NXapm_paraprobe_nanochem_results(NXobject): # Instances should use object as a name prefix. # # -# # # # # # # -# +# # # # @@ -2007,19 +1969,19 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # # -# +# # # # # -# +# # -# Array of identifier_evaporation / identifier_ion which details which ions +# Array of evaporation_id / identifier_ion which details which ions # lie inside or on the surface of the feature. # # @@ -2111,7 +2073,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # The triangle surface mesh representing the interface model. # Exported at state before or after the next DCOM step. -# +# # Instances should use mesh_state as a name prefix. # # @@ -2123,17 +2085,17 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# -# -# +# +# +# # -# -# -# -# -# -# -# +# +# +# +# +# +# +# # # # @@ -2157,7 +2119,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier which details how specifically oriented the # face normal is with respect to its primitive (triangle): -# +# # * 0 - undefined # * 1 - outer # * 2 - inner @@ -2166,7 +2128,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # @@ -2185,7 +2147,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier which details how specifically oriented the # face normal is with respect to its primitive (triangle): -# +# # * 0 - undefined # * 1 - outer # * 2 - inner @@ -2243,8 +2205,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # resolves the lateral surface of each cylinder such that their renditions are smooth in # visualization software like Paraview. # -# -# +# +# # # # Position of the geometric center, which often is but not @@ -2266,7 +2228,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # XDMF support to enable coloring each ROI by its identifier. # @@ -2355,9 +2317,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# -# -# +# +# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 00af839544..66fb973345 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -45,14 +45,14 @@ NXapm_paraprobe_ranger_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -60,7 +60,7 @@ NXapm_paraprobe_ranger_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -102,7 +102,7 @@ NXapm_paraprobe_ranger_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4c1f72db076800eedafc2113e0e44097edf7568c111c5f1c8e4e23cf8c978785 +# d6bd7ff3c66c1daf0e13df6fa1ad7a2edecf9560c6755c02105c25ea1a718706 # # # # # # @@ -210,9 +205,9 @@ NXapm_paraprobe_ranger_results(NXobject): # # # -# -# -# +# +# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 93528189bf..393a8480de 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -38,14 +38,14 @@ NXapm_paraprobe_selector_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): vertices(NX_UINT): cylinder_set(NXcg_cylinder): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): @@ -53,7 +53,7 @@ NXapm_paraprobe_selector_config(NXobject): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): - identifier_offset(NX_INT): + index_offset(NX_INT): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): @@ -94,7 +94,7 @@ NXapm_paraprobe_selector_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aed13f4eee9d8b16dd22984682ee073162ce868bbb10c5f0cf4600583c1b0e0c +# 01287da74ce6fcec4c36e74333ace77dea9cff4541e35e811572ebb2baa1f7cb # # # -# +# # # Number of vertices for each face. -# +# # Each entry represents the total number of vertices for that face, # irrespectively whether vertices are shared among faces or not. # @@ -253,10 +253,10 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # -# +# # # Number of edges for each face. -# +# # Each entry represents the total number of edges for that face, # irrespectively whether edges are shared across faces or not. # @@ -264,7 +264,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # -# +# # # Number of faces of the primitives. # @@ -273,7 +273,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the vertices differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -282,7 +282,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the edges differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -291,7 +291,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the faces differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -323,7 +323,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # Positions of the vertices. -# +# # Users are encouraged to reduce the vertices to a unique set as this may # result in more efficient storage. Alternatively, storing vertex positions naively # should be indicated with setting vertices_are_unique to False. @@ -347,12 +347,12 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # The faces are stored as a concatenated array of vertex identifier tuples. -# +# # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -372,7 +372,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # If true, indicates that no edge is stored more than once. -# +# # Users are encouraged to consider using a half_edge_data_structure instead. # # @@ -384,7 +384,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # 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_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index 86ee02e448..7981225356 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -78,7 +78,7 @@ NXcg_grid(NXcg_primitive): # does it have to be a tight bounding box? # 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_INT): + number_of_boundaries(NX_UINT): unit: NX_UNITLESS doc: | Number of boundaries distinguished @@ -127,7 +127,7 @@ NXcg_grid(NXcg_primitive): description can be used instead. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ae5f6a385db0e8c9c49989e03d512f279fbf61becb69b11c8fa012dbdb01893 +# c5bee596e67c2209b40728d8aef705108736ff7e8edce3781bd661d458bfbe13 # # # -# +# # # Number of boundaries distinguished -# +# # Most grids discretize a cubic or cuboidal region. In this case # six sides can be distinguished, each making an own boundary. # @@ -271,7 +271,7 @@ NXcg_grid(NXcg_primitive): # # # The boundary conditions for each boundary: -# +# # 0 - undefined # 1 - open # 2 - periodic @@ -288,17 +288,17 @@ NXcg_grid(NXcg_primitive): # Details about the computational geometry method and implementation # used for discretizing internal surfaces as e.g. obtained with marching methods, # like marching squares or marching cubes. -# +# # Documenting which specific version was used helps with understanding how # robust the results are with respect to the topology of the triangulation. # 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 ideally be an identifier of a program. # If not possible, an identifier for a paper, technical report, or free-text # description can be used instead. diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index be32c90341..1f5a471670 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -28,7 +28,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): Dimensionality of the primitives described. # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_INT): + number_of_vertices(NX_UINT): unit: NX_UNITLESS doc: | Number of vertices for each face. @@ -38,7 +38,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): dimensions: rank: 1 dim: (n_f,) - number_of_edges(NX_INT): + number_of_edges(NX_UINT): unit: NX_UNITLESS doc: | Number of edges for each face. @@ -143,7 +143,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): of microstructural objects like crystals/grains. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 18d27d46ae4ed64433baf02f09174dc4cc71eac48e42c1d001dcba99dd0ba54c +# b10ac48eea45ef41a87c498cb5948f0214ae0b644dac489dba9373b8f3afcff6 # # # -# +# # # Number of vertices for each face. -# +# # Each entry represents the total number of vertices for that face, # irrespectively whether vertices are shared among faces or not. # @@ -220,10 +220,10 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # # -# +# # # Number of edges for each face. -# +# # Each entry represents the total number of edges for that face, # irrespectively whether edges are shared across faces or not. # @@ -235,7 +235,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the vertices differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -244,7 +244,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the edges differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -253,7 +253,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the faces differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -329,11 +329,11 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # 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_polygon.yaml b/contributed_definitions/nyaml/NXcg_polygon.yaml index 7a27503b3f..bc715c1c7a 100644 --- a/contributed_definitions/nyaml/NXcg_polygon.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon.yaml @@ -38,7 +38,7 @@ symbols: The total number of vertices when visiting every polygon. type: group NXcg_polygon(NXcg_primitive): - number_of_total_vertices(NX_INT): + number_of_total_vertices(NX_UINT): unit: NX_UNITLESS doc: | The total number of vertices in the set. @@ -92,7 +92,7 @@ NXcg_polygon(NXcg_primitive): dim: (c,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 215bc01d38bbe6af8fdaf0103713d29e25a10a30e487976612729b465549c6d1 +# 8c9fc1ce7afe05d6d24acc8e928677470a1b760fb9993a6de023897554cf079d # # # # # Computational geometry description of a set of polygons in Euclidean space. -# +# # Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed # polyhedra. Even more general complexes can be thought of. An example are the # so-called piecewise-linear complexes used in the TetGen library. -# +# # As these complexes 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 to describe such even more complex primitives instead # of abusing this base class for such purposes. # -# +# # # The total number of vertices in the set. # @@ -178,14 +178,14 @@ NXcg_polygon(NXcg_primitive): # # # Individual storage of the mesh of each polygon. -# +# # Instances should use polygon as a name prefix. # # # # # Individual storage of each polygon as a graph. -# +# # Instances should use polygon_half_edge as a name prefix. # # @@ -213,7 +213,7 @@ NXcg_polygon(NXcg_primitive): # # # Curvature type: -# +# # * 0 - unspecified, # * 1 - convex, # * 2 - concave diff --git a/contributed_definitions/nyaml/NXcg_polyhedron.yaml b/contributed_definitions/nyaml/NXcg_polyhedron.yaml index 44ec1d3ddd..49ea708c61 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron.yaml @@ -32,7 +32,7 @@ type: group NXcg_polyhedron(NXcg_primitive): # qualifiers and properties of polyhedra - number_of_faces(NX_INT): + number_of_faces(NX_UINT): unit: NX_UNITLESS doc: | The number of faces for each polyhedron. Faces of adjoining polyhedra @@ -47,7 +47,7 @@ NXcg_polyhedron(NXcg_primitive): dimensions: rank: 1 dim: (n_f_total,) - number_of_edges(NX_INT): + number_of_edges(NX_UINT): doc: | The number of edges for each polyhedron. Edges of adjoining polyhedra are counted for each polyhedron. @@ -77,7 +77,7 @@ NXcg_polyhedron(NXcg_primitive): Instances should use cluster_analysis as a name prefix. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 59836c499259273600f4e8e9ecf9eb5f6810c21501fbe79a284e17e8ad8e9f90 +# 120c28ea7aaba11c216033c9576a1b068e7fecea8980a5c376648a1098c7cfc6 # # # -# +# # # The number of faces for each polyhedron. Faces of adjoining polyhedra # are counted for each polyhedron. @@ -161,7 +161,7 @@ NXcg_polyhedron(NXcg_primitive): # # # -# +# # # The number of edges for each polyhedron. Edges of adjoining polyhedra # are counted for each polyhedron. @@ -184,14 +184,14 @@ NXcg_polyhedron(NXcg_primitive): # # # Individual storage of each polyhedron. -# +# # Instances should use polyhedron as a name prefix. # # # # # Individual storage of each polygon as a graph. -# +# # Instances should use cluster_analysis as a name prefix. # # diff --git a/contributed_definitions/nyaml/NXcg_polyline.yaml b/contributed_definitions/nyaml/NXcg_polyline.yaml index cc720cf7b7..fffdef70d5 100644 --- a/contributed_definitions/nyaml/NXcg_polyline.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline.yaml @@ -27,15 +27,15 @@ NXcg_polyline(NXcg_primitive): Reference to an instance of :ref:`NXcg_point` which defines the location of the vertices that are referred to in this NXcg_polyline instance. - number_of_unique_vertices(NX_POSINT): + number_of_unique_vertices(NX_UINT): unit: NX_UNITLESS doc: | The total number of vertices that have different positions. - number_of_total_vertices(NX_INT): + number_of_total_vertices(NX_UINT): unit: NX_UNITLESS doc: | The total number of vertices, irrespective of their eventual uniqueness. - number_of_vertices(NX_INT): + number_of_vertices(NX_UINT): unit: NX_UNITLESS doc: | The total number of vertices of each polyline, irrespectively @@ -95,7 +95,7 @@ NXcg_polyline(NXcg_primitive): dim: (n_total,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f838ec9411d9e75d720c6e986fbaa571e08927458a68c6e48d9272421b5742b9 +# b14cc08d68ff1d70e5adca4bb17904235e53d9c9d2fd6c3aa5438efa188a2fed # # # # diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index 0b3de55b72..ddd58462cf 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -116,7 +116,7 @@ NXem_calorimetry(NXobject): as diffraction pattern matching with a specific state of the sample (e.g. obtained temperature via the actuator) are reported through delta_time. - indices_pattern(NX_UINT): + indices_pattern(NX_INT): unit: NX_UNITLESS dimensions: rank: 1 @@ -206,7 +206,7 @@ NXem_calorimetry(NXobject): rank: 2 dim: (n_p, n_f) \@long_name(NX_CHAR): - indices_pattern(NX_UINT): + indices_pattern(NX_INT): exists: optional unit: NX_UNITLESS doc: | @@ -241,7 +241,7 @@ NXem_calorimetry(NXobject): sequence_index(NX_POSINT): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 26d248fa2fd614cf7a292bfd7d31afe9380da6131ac94d9c1133d2bf167f157b +# ac8d97a8c318bd93e2c3c40f0804037d8d3d689d2ab0dca1ffcd370a8060f0a0 # # # -# +# # # How many distinct boundaries are distinguished? # Most grids discretize a cubic or cuboidal region. In this case @@ -659,7 +659,7 @@ NXmicrostructure_score_results(NXobject): # # # The boundary conditions for each boundary: -# +# # * 0 - undefined # * 1 - open # * 2 - periodic @@ -685,18 +685,18 @@ NXmicrostructure_score_results(NXobject): # # # Documentation of the spatiotemporal evolution for each CA domain. -# +# # SCORE is a hybrid parallelized code that can evolve multiple replicas # in parallel. The set of replicas is distributed across MPI processes. # Each such replica is then evolved via OpenMP multi-threading. -# +# # Instances should use spatiotemporal as a name prefix. # # # # # Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening for practical and performance reasons +# (averaging, integrating, interpolating) happening for practical and performance reasons # during the simulation. Place used for storing descriptors from continuum mechanics # and thermodynamics at the scale of the entire ROI. # @@ -847,7 +847,7 @@ NXmicrostructure_score_results(NXobject): # # # -# +# # # Index for each crystal whereby its metadata can be retrieved. # diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml index 2e77813737..99c2c2bd40 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -24,7 +24,7 @@ symbols: Total number of similarity groups aka features/clusters. type: group NXsimilarity_grouping(NXobject): - cardinality(NX_UINT): + cardinality(NX_POSINT): unit: NX_UNITLESS doc: | Number of members in the set which gets partitioned into features. @@ -107,7 +107,7 @@ NXsimilarity_grouping(NXobject): dim: (n_features, n_lbl_num) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d8b60f631586563552d4c727bb793166be42362ae44212106629ea2b4d58e3c0 +# 6dc338706ba4daa59db1cea7a343ebac413fe635c17f5869f9781bf3db2746c1 # # # - + Raw time-of-flight data without corrections. @@ -1100,8 +1099,6 @@ by proprietary hardware with proprietary semantics--> - @@ -1164,14 +1161,11 @@ results--> - + - @@ -1270,10 +1264,7 @@ results--> - + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 42f8dd0378..5795caed1c 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -301,7 +301,7 @@ for if desired all the dependencies and libraries--> Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - + Instances should use cluster_analysis as a name prefix. @@ -378,7 +378,7 @@ for if desired all the dependencies and libraries--> The maximum distance between voxel pairs in a neighborhood to be considered connected. - + Instances should use dbscan as a name prefix. @@ -399,7 +399,7 @@ for if desired all the dependencies and libraries--> Voxel identifier - + Using these identifiers correlated element-wise with the values in the label array specifies for which voxel in the grid clusters from this process were found. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index de2b6cd24e..4ad1bd1668 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -26,8 +26,7 @@ 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,7 +45,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> Application definition for a configuration file of the paraprobe-clusterer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -105,7 +104,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> @@ -113,7 +112,7 @@ the region of interest.--> This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - + Instances should use cluster_analysis as a name prefix. @@ -190,28 +189,28 @@ the region of interest.--> How should iontypes be considered during the cluster analysis. - + 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 nuclide structure. - + The value resolve_element will set an ion active and account as many times for it, as the (molecular) ion contains atoms of elements in the whitelist ion_query_nuclide_vector. - + The value resolve_isotope will set an ion active and account as many times for it, as the (molecular) ion contains nuclides in the whitelist ion_query_nuclide_vector. - + In effect, ion_query_nuclide_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 an ion of a molecular ion with more than one nuclide, say Ti O for example is counted potentially several times because at that position (reconstructed) position it has been assumed that @@ -240,10 +239,10 @@ the region of interest.--> Settings for DBScan clustering algorithm. For original details about the algorithm 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>`_ @@ -251,16 +250,16 @@ the region of interest.--> Strategy how a set of cluster analyses with different parameter is executed: - + * For tuple as many runs are performed as parameter values have been defined. * For combinatorics individual parameter arrays are looped over. - + As an example we may provide ten entries for eps and three entries for min_pts. If high_throughput_method is set to tuple, the analysis is invalid because we have an insufficient number of min_pts values to pair them with our ten eps values. By contrast, if high_throughput_method is set to combinatorics, the tool will run three individual min_pts runs for each eps value, resulting in a total of 30 analyses. - + A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. @@ -311,10 +310,10 @@ dim: (j,)--> 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. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 1d73c8dc59..09689bc998 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -39,7 +39,7 @@ Application definition for results files of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -68,7 +68,7 @@ Results of a DBScan clustering analysis. - + Instances should use dbscan as a name prefix. @@ -92,11 +92,11 @@ 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: * index_offset - 1 indicates an object belongs to no cluster. * index_offset - 2 indicates an object belongs to the noise category. - + Setting for instance index_offset to 1 recovers the commonly used case that objects of the noise category get the value of -1 and points of the unassigned category get the value 0. @@ -168,7 +168,7 @@ Weights for each target that specifies how probable the target is assigned to a specific cluster. - + For the DBScan algorithm and atom probe tomography this value is 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 diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 4a6cf8f3a8..5eb81b5a73 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -29,7 +29,7 @@ Application definition for a configuration file of the paraprobe-distancer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -107,7 +107,7 @@ Specifies for which point the tool will compute distances. - + The value *default* configures that distances are computed for all points. The value *skin* configures that distances are computed only for those points which are not farther away located to a triangle than @@ -139,7 +139,7 @@ array of NX_UINT incident vertices of each facet. Vertex indices are assumed to start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - + Instances should use triangle_set as a name prefix. diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 19d8b577bc..a1882331d7 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -39,16 +39,16 @@ Application definition for results files of the paraprobe-distancer tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the distance is computed as the projected distance, this tool evaluates robustly the exact distance between a point and a triangle. - + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. - + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, what their topology is, or whether or not these triangles are consistently oriented. @@ -108,7 +108,7 @@ A bitmask that identifies which of the distance values is assumed to have a consistent sign because the closest triangle had a consistent outer unit normal defined. - + For points whose bit is set to 0 the distance is correct but the sign is not reliable. diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 83473e73fe..82d5ac0f12 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -34,7 +34,7 @@ Application definition for a configuration file of the paraprobe-intersector tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -54,13 +54,13 @@ Tracking volume_volume_spatial_correlations (v_v) is the process of building logical relations between objects, their proximity and eventual volumetric intersections. Here, objects are assumed to be represented as a set of triangulated surface meshes. - + 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 :math:`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. - + Instances should use v_v_spatial_correlation as a name prefix. @@ -69,14 +69,14 @@ 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>`_, it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron intersections in paraprobe-intersector. diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index daaa3390cf..dd65baea33 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -59,7 +59,7 @@ Application definition for results files of the paraprobe-intersector tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -134,24 +134,24 @@ 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, pair relations are analyzed with respect to which objects with indices_feature cluster in identifier space. Thereby, a logical connection (link) is established between the features in the current_set and the next_set. Recall that these two sets 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 for precipitates B. - + Coprecipitation analysis now logically connects these independent characterization results to establish spatial correlations of e.g. the precipitates' spatial arrangement. @@ -191,10 +191,10 @@ 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 third column encodes the total number of members in the cluster. @@ -205,10 +205,10 @@ 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. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 0751e86a89..d9a3ba40e4 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -69,7 +69,7 @@ Application definition for a configuration file of the paraprobe-nanochem tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -83,10 +83,10 @@ Discretization and distributing of the ion point cloud on a 3D grid to enable continuum-scale analyses. - + By default, the tool computes a full kernel density estimation of decomposed ions to create one discretized field for each element. - + One delocalization task configures a parameter sweep with at least one delocalization. The total number of runs depends on the number of grid_resolution and kernel_variance values. For example, setting two grid_resolutions @@ -259,25 +259,25 @@ identifier(NX_UINT):--> times an ion is to be counted. The tool performs a so-called atomic decomposition of all iontypes, i.e. the tool analyses from how many atoms of each nuclide or element respectively an (molecular) ion is built from. - + Taking the hydroxonium H3O+ molecular ion as an example: It contains hydrogen and oxygen atoms. The multiplicity of hydrogen is three whereas that of oxygen is one. Therefore, the respective atomic decomposition analysis prior to the iso-surface computation adds three hydrogen counts for each H3O+ ion. - + This is a practical solution which accepts that on the one hand not every bond is broken during an atom probe experiment but also that ions may react further during their flight to the detector. The exact details depend on the local field conditions, quantum mechanics of possible electron transfer and thus the detailed trajectory of the system and its electronic state. - + The detection of molecular ions instead of always single atom ions only is the reason that an atom probe experiment tells much about field evaporation physics but also faces an inherent loss of information with respect to the detailed spatial arrangement that is independent of other imprecisions such as effect of limited accuracy of reconstruction protocols and their parameterization. - + Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. @@ -349,11 +349,11 @@ identifier(NX_UINT):--> composition-normalized delocalization. Here, it is possible that the composition increases towards the edge of the dataset because the quotient of two numbers that 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, keep_edge_triangles instructs the tool to not remove triangles at the edge of the dataset at the cost of bias. When using this keep_edge_triangles users should understand that all features in contact with the edge of the dataset get usually @@ -364,12 +364,12 @@ identifier(NX_UINT):--> of grain shapes via orientation microscopy from electron microscopy or X-ray diffraction tomography. Features at the edge of the dataset may have not been captured fully. - + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, paraprobe-nanochem implements a complete pipeline to process features at the edge of the dataset. Specifically, these are modelled and replaced with closed polyhedral objects using an iterative mesh and hole-filling procedures with fairing operations. - + The tool bookkeeps such objects separately to lead the decision whether or not to consider these objects to the user. Users should be aware that results from fairing operations should be compared to results from analyses where all objects at the edge @@ -379,7 +379,7 @@ identifier(NX_UINT):--> deliver statistically significant results for compositions, this does not necessarily mean that same dataset will also yield statistically significant and insignificantly biased results for 3D 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. @@ -392,7 +392,7 @@ identifier(NX_UINT):--> The ion-to-surface distance that is used in the analyses of features to identify whether these are laying inside the dataset or close to the surface (edge) of the dataset. - + If an object has at least one ion with an ion-to-surface-distance below this threshold, the object is considered close to the edge of the dataset. The tool uses a distance-based approach to solve the in general complicated and involved treatment of computing @@ -401,7 +401,7 @@ identifier(NX_UINT):--> robustness issues as a consequence of which a mesh can be detected as being completely inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost touching only the edge (e.g. from inside). - + Practically, humans would likely still 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 flexible. @@ -412,11 +412,12 @@ identifier(NX_UINT):--> Iso-contour values. For each value, the tool computes an iso-surface and performs subsequent analyses for each iso-surface. 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 + @@ -424,7 +425,7 @@ identifier(NX_UINT):--> Specifies if the tool should report the triangle soup which represents each triangle of the iso-surface complex. The resulting set of triangles is colloquially referred to as a soup because different sub-set may not be connected. - + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) the triangle belongs. The clustering of triangles within the soup is performed with a modified DBScan algorithm. @@ -435,12 +436,12 @@ identifier(NX_UINT):--> 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 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 scandium-rich precipitates in aluminum alloys which in reconstructions may appear as ellipsoids although they should be indeed almost spherical @@ -452,7 +453,7 @@ identifier(NX_UINT):--> 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 tiny sub-complexes (e.g. small isolated tetrahedra). - + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid on which marching cubes operates. Such objects may not contain an ion; especially when considering that delocalization procedures smoothen the positions of the ions. Although these small objects are @@ -473,7 +474,7 @@ identifier(NX_UINT):--> 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). - + Users should be aware that the choice of the algorithm to compute the bounding box can have an effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms @@ -485,7 +486,7 @@ identifier(NX_UINT):--> Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector tool to infer if two objects share common ions, which is then understood as 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 and flat face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of @@ -493,7 +494,7 @@ identifier(NX_UINT):--> might be so small or happening in the volume between two reconstructed ion positions. Consequently, sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections between objects. - + 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 @@ -514,7 +515,7 @@ identifier(NX_UINT):--> Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose combinatorial analysis according to has_object returned 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 feature. In most cases objects, precipitates in atom probe end up as open objects because they have been clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account @@ -561,7 +562,7 @@ identifier(NX_UINT):--> via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. Otherwise, the ROI is assumed to make no edge contact. - + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant provided constructions such as alpha shapes or alpha wrappings (such as paraprobe-surfacer does) about the @@ -578,7 +579,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> Use a principle component analysis (PCA) to mesh a single free-standing interface patch within the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). - + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess in cases when closed objects constructed from patches e.g. iso-surfaces are not available or when there is no substantial or consistently oriented concentration gradients across an interface @@ -586,7 +587,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> within the point cloud is insufficient or when combined with interface_meshing based on ion density traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). - + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations paraprobe-nanochem uses inspection functionalities which detect potential geometric inconsistencies or self-interactions of the evolved DCOM mesh. @@ -682,11 +683,11 @@ identifier(NX_UINT):--> How is the PCA initialized: - + * 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>`_ creates a control_point_file that can be parsed by paraprobe-parmsetup-nanochem to match the here required @@ -763,7 +764,7 @@ identifier(NX_UINT):--> 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 might be relocated. - + The larger it is the DCOM radius in relation to the target_edge_length the more likely it becomes that vertices will be relocated so substantially that triangle self-intersections may occur. The tool detects these and stops in a controlled @@ -792,21 +793,21 @@ identifier(NX_UINT):--> Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying interfacial excess or for performing classical composition analyses. - + The tool will test for each ROIs if it is completely embedded in the dataset. Specifically, each such test evaluates if the ROI cuts at least one triangle of the triangulated surface mesh that is referred to by surface. If this is the case the ROI is marked as one close to the surface and not analyzed further. Otherwise, the ROI is marked as one far from the surface and processed further. - + For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into nuclides as many times as their respective multiplicity. For each processed ROI the tool stores a sorted list of signed distance values to enable post-processing with other software like e.g. reporter to perform classical Krakauer/Seidman-style interfacial excess analyses. - + Users should be aware that the latter intersection analysis is not a volumetric intersection analysis. Given that the triangulated mesh referred to in surface is not required to mesh neither a watertight diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index a40f1a9ad4..64740d727c 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -86,7 +86,7 @@ The cardinality/total number of triangles in the triangle soup.--> Application definition for results files of the paraprobe-nanochem tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -279,12 +279,12 @@ The cardinality/total number of triangles in the triangle soup.--> 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -324,13 +324,14 @@ The cardinality/total number of triangles in the triangle soup.--> The boundary conditions for each boundary: - + 0 - undefined 1 - open 2 - periodic 3 - mirror 4 - von Neumann 5 - Dirichlet + @@ -343,10 +344,10 @@ The cardinality/total number of triangles in the triangle soup.--> The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. - + If the intensity for all matches of the weighting_model are summarized name this NXdata instance scalar_field_magn_total. - + If the intensity is reported for each iontype one can avoid many subsequent computations as individual intensities can be reinterpreted using a different weighting_model in down-stream usage of the here reported values (e.g. with Python scripting). @@ -502,12 +503,12 @@ The cardinality/total number of triangles in the triangle soup.--> An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - + Instances should iso_surface as a name prefix. - + For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. - + This yields a complex of not necessarily connected geometric primitives. Paraprobe-nanochem approximates this complex with a soup of triangles. @@ -541,7 +542,7 @@ The cardinality/total number of triangles in the triangle soup.--> Positions of the vertices. - + Users are encouraged to reduce the vertices to a unique set as this may result in a more efficient storage of the geometry data. It is also possible though to store the vertex positions naively in which @@ -556,12 +557,12 @@ The cardinality/total number of triangles in the triangle soup.--> 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -594,10 +595,11 @@ The cardinality/total number of triangles in the triangle soup.--> Qualifier how which specifically oriented normal to its primitive each normal represents. - + * 0 - undefined * 1 - outer * 2 - inner + @@ -620,10 +622,11 @@ exists: optional--> Qualifier how which specifically oriented normal to its primitive each normal represents. - + * 0 - undefined * 1 - outer * 2 - inner + @@ -708,9 +711,9 @@ dim: (k,)--> This may yield a set of connected features whose individual surfaces are discretized by a triangulated mesh each. Such volumetric features can be processed further using paraprobe-nanochem using a workflow with at most two steps. - + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. These objects were already watertight within the triangulated iso-surface. 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated @@ -719,11 +722,11 @@ dim: (k,)--> 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality that are not transformable into proxies or for which no transformation into proxies was instructed. - + 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. - + In the second step, the tool can be used to analyze the proximity of these objects to a model of the surface (edge) of the dataset. @@ -778,13 +781,14 @@ dim: (k,)--> In all situations instances of the parent NXprocess group are returned with a very similar information structuring and thus we here replace the template name FEATURE with one of the following types feature-specific group names: - + * objects, objects, irrespective their distance to the surface * objects_close_to_edge, sub-set of v_feature_object close surface * objects_far_from_edge, sub-set of v_feature_object not close to the surface * proxies, proxies, irrespective their distance to the surface * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface + @@ -989,7 +993,7 @@ MK::namely k != i each OBB has eight vertices--> The triangle surface mesh representing the interface model. Exported at state before or after the next DCOM step. - + Instances should use mesh_state as a name prefix. @@ -1035,10 +1039,11 @@ MK::namely k != i each OBB has eight vertices--> Qualifier which details how specifically oriented the face normal is with respect to its primitive (triangle): - + * 0 - undefined * 1 - outer * 2 - inner + @@ -1063,10 +1068,11 @@ MK::namely k != i each OBB has eight vertices--> Qualifier which details how specifically oriented the face normal is with respect to its primitive (triangle): - + * 0 - undefined * 1 - outer * 2 - inner + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 30e0e1ecbf..c6db083099 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -40,7 +40,7 @@ Application definition for a configuration file of the paraprobe-ranger tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index eb6ad19d97..0ba13df6c8 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -34,7 +34,7 @@ Application definition for results files of the paraprobe-ranger tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within a certain (possibly complicated) selection of ions (based on their properties or location in the diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 55c25e1431..5bb234ab19 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -29,7 +29,7 @@ Application definition for a configuration file of the paraprobe-selector tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 9937928945..bcbb21f6d1 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -34,7 +34,7 @@ Application definition for results files of the paraprobe-selector tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 44053f3209..1efc23a85d 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -44,7 +44,7 @@ Application definition for a configuration file of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -94,10 +94,10 @@ of the dataset so that the ion can act as a source. This means that an ROI is placed at the location of the ion and its neighbors are analyzed how they contribute to the computed statistics. - + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a microstructural feature an ROI is placed. - + The threshold is useful to process the dataset such that ROIs do not protrude out of the dataset as this would add bias. @@ -127,7 +127,7 @@ 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 this feature_distance threshold is used in combination with the edge_distance threshold when placing ROI about source ions. @@ -205,25 +205,25 @@ identifier(NX_UINT):--> 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 diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index b21ba6c8e1..4da6d04eda 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -44,7 +44,7 @@ Application definition for results files of the paraprobe-spatstat tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -70,7 +70,7 @@ 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 remain the same. - + The order matches the iontypes array from a given ranging results as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index 994310a8ec..8bd9dbe0fd 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -39,7 +39,7 @@ Application definition for a configuration file of the paraprobe-surfacer tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -121,7 +121,7 @@ Specifies the method that is used to preprocess the point cloud prior to the alpha-shape computation. - + The option *default* specifies that no such filtering is applied. The option *kuehbach* specifies that a Hoshen-Kopelman percolation analysis is used to identify points that lie closer @@ -144,18 +144,18 @@ Specifies which method to use to define the alpha value. - + The value *convex_hull_naive* is the default. The setting 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* instructs to tool to refine the quality of the mesh resulting from *convex_hull_naive* via triangle flipping and splitting. - + 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 CGAL library to choose a value which the library considers as to be an optimal value. Details are defined in the respective section of the CGAL library diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 98ff985bc0..dc4d4d1f9b 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -54,7 +54,7 @@ Application definition for results files of the paraprobe-surfacer tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-surfacer tool is the generation of meshed representation of the surface of the the reconstructed volume (or a portion) of it @@ -75,11 +75,11 @@ 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. @@ -102,7 +102,7 @@ for eventually performed preprocessing--> A bitmask which identifies exactly all those ions whose positions were considered when defining the filtered point set from which that alpha_complex instance was computed. - + This window can be different to the window of the *point_set_wrapping* parent group because irrelevant ions might have been filtered out in addition to the window defined in *point_set_wrapping* to reduce e.g. computational diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index cf1136e8f6..a42f0d1e24 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -30,7 +30,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin Application definition for a configuration file of the paraprobe-tessellator tool. - + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index faca2730a6..08b9e0e92c 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -45,7 +45,7 @@ Application definition for results files of the paraprobe-tessellator tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index 56d549b7a4..089aa8c416 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -24,21 +24,21 @@ Base class documenting the information common to tools of the paraprobe-toolbox. - + The paraprobe-toolbox is a collection of open-source tools for performing efficient analyses of point cloud data where each point can represent atoms or (molecular) ions. A key application of the toolbox has been for research in the field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - + The toolbox does not replace but complements existent software tools in this research field. Given its capabilities of handling points as objects with properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - + The common section can be used as a place to store e.g. organizational metadata and contextualization of that analysis in a research data management system. @@ -49,7 +49,7 @@ or whether this failed. Status is written to the results file after the end_time beyond which point in time the tool must no longer compute any further analysis results but exit. - + Only when this status message is present and its value is `success`, one should consider the results of the tool. In all other cases it might be that the tool has terminated prematurely or another error occurred. @@ -104,7 +104,7 @@ 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: - + * paraprobe * lab * specimen @@ -112,7 +112,7 @@ * 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 diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 79eb264db0..6b66ef1fca 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -24,21 +24,21 @@ Base class documenting the configuration used for a tool of the paraprobe-toolbox. - + The paraprobe-toolbox is a collection of open-source software tools for performing efficient analyses of point cloud data where each point can represent atoms or (molecular) ions. A key application of the toolbox has been for research in the field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - + The toolbox does not replace but complements existent software tools in this research field. Given its capabilities of handling points as objects with properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - + The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). @@ -53,7 +53,7 @@ Possibility for leaving a free-text description about this analysis. - + Although offered here for convenience we strongly encourage to parameterize such descriptions as much as possible to support reusage and clearer communication. @@ -64,7 +64,7 @@ base class from which tool-specific application definitions inherit--> Specification of the tomographic reconstruction to use for this analysis. - + Typically, reconstructions in the field of atom probe tomography are communicated via files which store at least reconstructed ion positions and mass-to-charge-state-ratio values. Container files like HDF5 though can store multiple reconstructions. @@ -87,12 +87,12 @@ base class from which tool-specific application definitions inherit--> Specification of the ranging definitions to use for this analysis. - + Ranging is the process of labeling time-of-flight data with so-called iontypes (aka ion species). Ideally, iontypes specify the most likely (molecular) ion that is assumed to have been evaporated given that its mass-to-charge-state ratio lies within the specific mass-to-charge-state-ratio value interval of the iontype. - + The so-called UNKNOWNTYPE iontype represents the null model of an ion that has not been ranged (for whatever reasons). The identifier of this special iontype is always the reserved value 0. @@ -107,7 +107,7 @@ base class from which tool-specific application definitions inherit--> Specification of the triangulated surface mesh to use for this analysis. - + Such a surface mesh can be used to define the edge of the reconstructed volume to account for finite size effects. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 2b5aeece09..49631929b3 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -52,25 +52,25 @@ i be careful n_comb can vary for every instance of (NXion) !--> Application definition for results files of the paraprobe-transcoder tool. - + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to exchange information especially when it comes to the communication of configurations and results from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document their origin and thus the sequence in which the file was generated during an analysis. - + Paraprobe-transcoder solves this limitation by interpreting the information content in such files and standardize the representation prior injection into the scientific data analysis tools of the toolbox. Therefore, the here proposed set of NeXus base classes and application definitions can be a useful starting point for the atom probe community to take advantage of standardized information exchange and improve the here proposed classes and concepts to become more inclusive. - + Paraprobe-transcoder uses a Python library developed based on efforts by members of the global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the actual low-level I/O operations and respective information interpretation of above-mentioned file formats. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 1b1134c368..40c3bdc616 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -56,26 +56,26 @@ duplicate of an NXoff_geometry ?--> Computational geometry of primitives via a face-and-edge-list data structure. - + Primitives must neither be degenerated nor self-intersect but can have different properties. A face-and-edge-list-based description of primitives is frequently used for triangles and polyhedra to store them on disk for visualization purposes (see OFF, PLY, VTK, or STL file formats). - + Although this description is storage efficient, it is not well-suited for topological analyses. In this case using a half-edge data structure is an alternative. - + Having an own base class for the data structure how primitives are stored is useful to embrace both users with small or detailed specification demands. - + Indices can be used as identifier and thus names for individual instances. Number of vertices for each face. - + Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. @@ -86,7 +86,7 @@ duplicate of an NXoff_geometry ?--> Number of edges for each face. - + Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. @@ -103,7 +103,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the vertices differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -112,7 +112,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the edges differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -121,7 +121,7 @@ duplicate of an NXoff_geometry ?--> Integer offset whereby the identifier of the first member of the faces differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive for further details. @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Positions of the vertices. - + Users are encouraged to reduce the vertices to a unique set as this may result in more efficient storage. Alternatively, storing vertex positions naively should be indicated with setting vertices_are_unique to False. @@ -177,12 +177,12 @@ duplicate of an NXoff_geometry ?--> The faces are stored as a concatenated array of vertex identifier tuples. - + 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> If true, indicates that no edge is stored more than once. - + Users are encouraged to consider using a half_edge_data_structure instead. @@ -214,10 +214,11 @@ duplicate of an NXoff_geometry ?--> 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_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 00ea6f1a71..f9d57a4386 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -44,7 +44,7 @@ Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - + Three-dimensional grids with cubic cells are if not the most frequently used example of such grids. Numerical methods and models that use grids are used in many cases in the natural sciences and engineering disciplines. Examples are @@ -54,7 +54,7 @@ Location of the origin of the grid. - + Use the depends_on field that is inherited from the :ref:`NXcg_primitive` class to specify the coordinate system in which the origin location is defined. @@ -81,7 +81,7 @@ 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 @@ -124,7 +124,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Number of boundaries distinguished - + Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. @@ -141,13 +141,14 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele The boundary conditions for each boundary: - + 0 - undefined 1 - open 2 - periodic 3 - mirror 4 - von Neumann 5 - Dirichlet + @@ -158,17 +159,17 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Details about the computational geometry method and implementation used for discretizing internal surfaces as e.g. obtained with marching methods, like marching squares or marching cubes. - + Documenting which specific version was used helps with understanding how robust the results are with respect to the topology of the triangulation. 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 ideally be an identifier of a program. If not possible, an identifier for a paper, technical report, or free-text description can be used instead. diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index db7a88818d..8f5a90d162 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -50,11 +50,11 @@ Computational geometry 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. The data structure is also known as a doubly connected edge list. - + Indices can be used as identifier and thus names for individual instances. @@ -66,7 +66,7 @@ Number of vertices for each face. - + Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. @@ -77,7 +77,7 @@ Number of edges for each face. - + Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. @@ -89,7 +89,7 @@ Integer offset whereby the identifier of the first member of the vertices differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -98,7 +98,7 @@ Integer offset whereby the identifier of the first member of the edges differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -107,7 +107,7 @@ Integer offset whereby the identifier of the first member of the faces differs from zero. - + Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -183,11 +183,11 @@ 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_polygon.nxdl.xml b/contributed_definitions/NXcg_polygon.nxdl.xml index 7c88a41589..3288112efd 100644 --- a/contributed_definitions/NXcg_polygon.nxdl.xml +++ b/contributed_definitions/NXcg_polygon.nxdl.xml @@ -46,24 +46,24 @@ Computational geometry description of a set of polygons in Euclidean space. - + Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed polyhedra. Even more general complexes can be thought of. An example are the so-called piecewise-linear complexes used in the TetGen library. - + As these complexes 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 to describe such even more complex primitives instead @@ -83,14 +83,14 @@ Individual storage of the mesh of each polygon. - + Instances should use polygon as a name prefix. Individual storage of each polygon as a graph. - + Instances should use polygon_half_edge as a name prefix. @@ -118,10 +118,11 @@ Curvature type: - + * 0 - unspecified, * 1 - convex, * 2 - concave + diff --git a/contributed_definitions/NXcg_polyhedron.nxdl.xml b/contributed_definitions/NXcg_polyhedron.nxdl.xml index 257472e3b6..d2df280a04 100644 --- a/contributed_definitions/NXcg_polyhedron.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron.nxdl.xml @@ -54,11 +54,11 @@ for clean graph-based descriptions of polyhedra.--> Computational geometry description of a set of polyhedra in Euclidean space. - + Polyhedra or so-called cells (especially in the convex of tessellations) are constructed from polygon meshes. Polyhedra may make contact to allow a usage of this base class for a description of tessellations. - + For the description of more complicated manifolds and especially for polyhedra with holes, users are advised to check if their particular needs are described by creating customized instances of an :ref:`NXcg_polygon`. @@ -104,14 +104,14 @@ for clean graph-based descriptions of polyhedra.--> Individual storage of each polyhedron. - + Instances should use polyhedron as a name prefix. Individual storage of each polygon as a graph. - + Instances should use cluster_analysis as a name prefix. diff --git a/contributed_definitions/NXcg_polyline.nxdl.xml b/contributed_definitions/NXcg_polyline.nxdl.xml index 6ecc901fb8..3ad6b7848d 100644 --- a/contributed_definitions/NXcg_polyline.nxdl.xml +++ b/contributed_definitions/NXcg_polyline.nxdl.xml @@ -51,7 +51,7 @@ multiple vertices possible with the same point coordinates but different names.- Computational geometry description of a set of polylines. - + 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 traversal along the polyline when @@ -90,7 +90,7 @@ they share the same position in space but have different identifiers.--> Positions of the vertices which support the members of the polyline set. - + Users are encouraged to reduce the vertices to unique positions and vertices as this often supports with storing geometry data more efficiently. It is also possible though to store the vertex positions naively @@ -114,17 +114,17 @@ they share the same position in space but have different identifiers.--> Sequence of identifier for vertices how they build each polyline. - + A trivial example is a set with two polylines with three vertices each. If the polylines meet at a vertex (assume for example that the second vertex is shared and marking the junction between the two polylines), it is possible that there are only five unique positions. This suggests to store five unique vertices. - + A non-trivial example is a set with several polylines. Assume that each has a different number of vertices. The array stores the identifier of the vertices in the sequence how the polylines are visited: - + The first entry is the identifier of the first vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex of the first polyline. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index da136e2920..e09aead2ba 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -44,36 +44,36 @@ Base class for packing and unpacking booleans. - + This base class bookkeeps metadata to inform software about necessary modulo operations to decode e.g. set membership of objects in sets which are encoded as a packed array of boolean values. - + One use case is processing of object sets (e.g. point cloud data). If e.g. a spatial filter has been applied to a set of points we may wish to store document efficiently which points were analyzed. Array of boolean values is one option to achieve this. A value is true if the point is included. The resulting boolean array will be filled with true and false values in a manner that is often arbitrary and in general case-dependent. - + Especially when the number of points is large, for instance several thousands or more, some situations can be more efficiently stored if one does not store the boolean array but just lists the identifiers of the points taken. - + For example, if within a set of 1000 points only one point is included, it would take (naively) 4000 bits to store the array but only 32 bits to store e.g. the ID of the single point that is taken. 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 in that they store compact representation of set memberships. - + This base class can deal with the situation when the number of objects is not an integer multiple of the bit depth used for storing the states. Possibility to refer to which set this mask applies. - + If depends_on is not provided, it is assumed that the mask applies to its direct parent. diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index cf4ff1883c..a106792656 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -53,12 +53,13 @@ are aligned with what and how to name things--> Application definition for minimal example in-situ calorimetry. - + TODO: - + * What is the technique about. * General context. * Literature references. + @@ -107,7 +108,7 @@ are aligned with what and how to name things--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources. @@ -121,7 +122,7 @@ are aligned with what and how to name things--> Reference to the resource which stores acquired pattern from the experiment or simulation that are analyzed in this workflow. - + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. @@ -157,7 +158,7 @@ are aligned with what and how to name things--> with which delta_time can be converted in timestamp. The reference timestamp is defined as the time when the actuator started acting on the sample. - + Time differences to this timestamp when correlated signals such as diffraction pattern matching with a specific state of the sample (e.g. obtained temperature via the actuator) are reported through @@ -172,7 +173,7 @@ are aligned with what and how to name things--> Time difference to start_time. - + Collecting diffraction pattern also takes some time. It is assumed that the acquisition time for each pattern is substantial shorter than the time it takes the actuator to @@ -239,9 +240,10 @@ NXcg_ellipsoid--> The integrated intensities: - + * result_with_background * result_without_background + diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 88d753c106..ed76c6558f 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -53,7 +53,7 @@ - + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 02c52005fc..b5061cd9df 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -72,9 +72,10 @@ Application definition to configure a simulation with the SCORE model. - + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + @@ -126,7 +127,7 @@ exists: optional--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from other sources. @@ -185,11 +186,12 @@ SecondOrderThermalExpCoeff--> Which model should be used to generate a starting microstructure. - + * cuboidal, a regular array of equally shaped cuboidal grains * poisson_voronoi, a discretized poisson voronoi * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. + @@ -288,10 +290,11 @@ SecondOrderThermalExpCoeff--> According to which model will the nuclei become distributed spatially: - + * csr, complete spatial randomness * custom, implementation-specific * gb, nuclei placed at grain boundaries + @@ -309,10 +312,11 @@ SecondOrderThermalExpCoeff--> According to which model will the nuclei get their orientation assigned: - + * ensemble, picking randomly one from ensemble/bunge_euler * random, picking randomly on the SO3 * damask, picking based on information provided in deformation/damask + @@ -355,7 +359,7 @@ SecondOrderThermalExpCoeff--> Which type of fundamental model for the grain boundary mobility. - + Grain boundaries with disorientation angle smaller than 15 degree are considered as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. @@ -655,7 +659,7 @@ like showing a r(t) plot--> with up to :math:`1600^3` cells. Snapshot data document the current microstructure including the assignment of grains and cells surplus the state of the recrystallization front. - + Despite these front data make up for approximately one order of magnitude less cells than represented in the domain, more numerical data have to be collected for each cell in the front than just a grain identifier. diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 90c554cc19..74a283d937 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -72,18 +72,19 @@ inspect comments behind NXmicrostructure--> Application definition for storing results of the SCORE cellular automata model. - + The SCORE cellular automata model for primary recrystallization is an example of a typical materials engineering application 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 nuclei during static recrystallization. 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>`_ + @@ -221,13 +222,14 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele The boundary conditions for each boundary: - + * 0 - undefined * 1 - open * 2 - periodic * 3 - mirror * 4 - von Neumann * 5 - Dirichlet + @@ -247,11 +249,11 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Documentation of the spatiotemporal evolution for each CA domain. - + SCORE is a hybrid parallelized code that can evolve multiple replicas in parallel. The set of replicas is distributed across MPI processes. Each such replica is then evolved via OpenMP multi-threading. - + Instances should use spatiotemporal as a name prefix. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 72601c6e7d..3cd867e22b 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -49,11 +49,11 @@ Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - + Similarity grouping algorithms are segmentation or machine learning algorithms for partitioning the members of a set of objects (e.g. geometric primitives) into (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - + This base class considers metadata and results of having a similarity grouping algorithm applied to a set in which objects are either categorized as noise or belonging to a cluster, i.e. members of a cluster. @@ -84,7 +84,7 @@ results for the object set--> Which numerical index is the first to be used to label a feature. - + The value should be chosen in such a way that special values can be resolved: * index_offset - 1 indicates that an object belongs to no cluster. * index_offset - 2 indicates that an object belongs to the noise category. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 46ca0ef407..e8d4444fed 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -967,8 +967,7 @@ NXapm(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): - # currently cannot be made required because of being a quantity measured - # by proprietary hardware with proprietary semantics + # currently cannot be made required proprietary hardware and semantics raw_tof(NX_FLOAT): exists: recommended doc: | @@ -1004,9 +1003,6 @@ NXapm(NXobject): file_name(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - - # config/input - # results mass_to_charge(NX_FLOAT): dimensions: rank: 1 @@ -1069,16 +1065,12 @@ NXapm(NXobject): program(NX_CHAR): \@version(NX_CHAR): - # config/input # results (NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_UINT): nameType: partial - - # dim: (3,) - # \@long_name: title(NX_CHAR): exists: recommended intensity(NX_NUMBER): @@ -1170,10 +1162,7 @@ NXapm(NXobject): doc: | MRP, at which mrp_value was specified. - # config/input - # results - # NEW ISSUE: add parameters of the background model - # in an e.g. work of A. London et al. + # TODO add description of background models and fit like in XPS peak_search(NXprocess): exists: recommended sequence_index(NX_POSINT): @@ -1245,7 +1234,7 @@ NXapm(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aea11bb9aa74ed5e31c1738b97420a496268f2571756bc53119e74cc2b082014 +# 60b2bc45c73a1c8918e6bbd792bd2fc603c0fbfe0f054bb53350b2f4d3f6a3a1 # # # +# # # # Raw time-of-flight data without corrections. @@ -2348,8 +2336,6 @@ NXapm(NXobject): # # # -# # # # @@ -2412,14 +2398,11 @@ NXapm(NXobject): # # # -# +# # # # # -# # # # @@ -2518,10 +2501,7 @@ NXapm(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index c653d68b64..5388c238ec 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -613,7 +613,7 @@ NXapm_compositionspace_results(NXobject): # # # Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. -# +# # Instances should use cluster_analysis as a name prefix. # # @@ -690,7 +690,7 @@ NXapm_compositionspace_results(NXobject): # # The maximum distance between voxel pairs in a neighborhood # to be considered connected. -# +# # Instances should use dbscan as a name prefix. # # @@ -711,7 +711,7 @@ NXapm_compositionspace_results(NXobject): # # # Voxel identifier -# +# # Using these identifiers correlated element-wise with the values in the label array # specifies for which voxel in the grid clusters from this process were found. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 260bf3e29a..e5e95fafd0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -7,8 +7,7 @@ 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, n_disjoint_clusters n_ivec_max: | Maximum number of atoms per molecular ion. Should be 32 for paraprobe. n_clust_algos: | @@ -65,7 +64,7 @@ NXapm_paraprobe_clusterer_config(NXobject): # 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 + # evaporation_id 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. @@ -313,7 +312,7 @@ NXapm_paraprobe_clusterer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d03710e6b442eac4b69a38a86f9a82157658d23a31610dfeba414aa5c1e686e6 +# 1691c2daa6cb56352236811442d1bd014249aa443f9e7361ba4f99106665d071 # # # +# # # # Maximum number of atoms per molecular ion. Should be 32 for paraprobe. @@ -362,7 +360,7 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # Application definition for a configuration file of the paraprobe-clusterer tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -421,7 +419,7 @@ NXapm_paraprobe_clusterer_config(NXobject): # @@ -429,7 +427,7 @@ NXapm_paraprobe_clusterer_config(NXobject): # # This process performs a cluster analysis on a # reconstructed dataset or a ROI within it. -# +# # Instances should use cluster_analysis as a name prefix. # # @@ -506,28 +504,28 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # How should iontypes be considered during the cluster analysis. -# +# # 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 nuclide structure. -# +# # The value resolve_element will set an ion active and account as many times # for it, as the (molecular) ion contains atoms of elements in the whitelist # ion_query_nuclide_vector. -# +# # The value resolve_isotope will set an ion active and account as many times # for it, as the (molecular) ion contains nuclides in the whitelist # ion_query_nuclide_vector. -# +# # In effect, ion_query_nuclide_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 an ion of a molecular # ion with more than one nuclide, say Ti O for example is counted potentially several # times because at that position (reconstructed) position it has been assumed that @@ -556,10 +554,10 @@ NXapm_paraprobe_clusterer_config(NXobject): # # Settings for DBScan clustering algorithm. For original details about the # algorithm 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>`_ @@ -567,16 +565,16 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # Strategy how a set of cluster analyses with different parameter is executed: -# +# # * For tuple as many runs are performed as parameter values have been defined. # * For combinatorics individual parameter arrays are looped over. -# +# # As an example we may provide ten entries for eps and three entries for min_pts. # If high_throughput_method is set to tuple, the analysis is invalid because we have # an insufficient number of min_pts values to pair them with our ten eps values. # By contrast, if high_throughput_method is set to combinatorics, the tool will run three # individual min_pts runs for each eps value, resulting in a total of 30 analyses. -# +# # A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ # can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), # one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. @@ -627,10 +625,10 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # 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. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index d98ad093ad..8fa905702a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -284,7 +284,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # Application definition for results files of the paraprobe-spatstat tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # @@ -313,7 +313,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # Results of a DBScan clustering analysis. -# +# # Instances should use dbscan as a name prefix. # # @@ -337,11 +337,11 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # 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: # * index_offset - 1 indicates an object belongs to no cluster. # * index_offset - 2 indicates an object belongs to the noise category. -# +# # Setting for instance index_offset to 1 recovers the commonly used # case that objects of the noise category get the value of -1 and points of the # unassigned category get the value 0. @@ -413,7 +413,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # Weights for each target that specifies how probable the target is assigned to # a specific cluster. -# +# # For the DBScan algorithm and atom probe tomography this value is 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 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index b6d48383f1..015e6dd580 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -194,7 +194,7 @@ NXapm_paraprobe_distancer_config(NXobject): # # # Application definition for a configuration file of the paraprobe-distancer tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -272,7 +272,7 @@ NXapm_paraprobe_distancer_config(NXobject): # # # Specifies for which point the tool will compute distances. -# +# # The value *default* configures that distances are computed for all points. # The value *skin* configures that distances are computed only for those # points which are not farther away located to a triangle than @@ -304,7 +304,7 @@ NXapm_paraprobe_distancer_config(NXobject): # array of NX_UINT incident vertices of each facet. Vertex indices are assumed to # start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. # Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. -# +# # Instances should use triangle_set as a name prefix. # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index bbd51e97a0..3d02a9dc7e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -200,16 +200,16 @@ NXapm_paraprobe_distancer_results(NXobject): # # # Application definition for results files of the paraprobe-distancer tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each # member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the # distance is computed as the projected distance, this tool evaluates robustly the exact distance between # a point and a triangle. -# +# # Triangles can represent for instance the facets of a triangulated surface mesh like those returned by # paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. -# +# # Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, # what their topology is, or whether or not these triangles are consistently oriented. # @@ -269,7 +269,7 @@ NXapm_paraprobe_distancer_results(NXobject): # A bitmask that identifies which of the distance values is # assumed to have a consistent sign because the closest # triangle had a consistent outer unit normal defined. -# +# # For points whose bit is set to 0 the distance is correct # but the sign is not reliable. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 2fe3ec4819..13768e7c68 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -244,7 +244,7 @@ NXapm_paraprobe_intersector_config(NXobject): # # # Application definition for a configuration file of the paraprobe-intersector tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -264,13 +264,13 @@ NXapm_paraprobe_intersector_config(NXobject): # Tracking volume_volume_spatial_correlations (v_v) is the process of building logical # relations between objects, their proximity and eventual volumetric intersections. # Here, objects are assumed to be represented as a set of triangulated surface meshes. -# +# # 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 :math:`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. -# +# # Instances should use v_v_spatial_correlation as a name prefix. # # @@ -279,14 +279,14 @@ NXapm_paraprobe_intersector_config(NXobject): # 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>`_, # it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron # intersections in paraprobe-intersector. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 1fa3e15a18..aeb66b2f49 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -272,7 +272,7 @@ NXapm_paraprobe_intersector_results(NXobject): # # # Application definition for results files of the paraprobe-intersector tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # @@ -347,24 +347,24 @@ NXapm_paraprobe_intersector_results(NXobject): # 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, pair relations # are analyzed with respect to which objects with indices_feature # cluster in identifier space. Thereby, a logical connection (link) is # established between the features in the current_set and the next_set. # Recall that these two sets 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 for precipitates B. -# +# # Coprecipitation analysis now logically connects these independent # characterization results to establish spatial correlations of e.g. # the precipitates' spatial arrangement. @@ -404,10 +404,10 @@ NXapm_paraprobe_intersector_results(NXobject): # 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 third column encodes the total number of members in the cluster. # # @@ -418,10 +418,10 @@ NXapm_paraprobe_intersector_results(NXobject): # # # 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. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index aef7dc3fd9..ff149b91bd 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -937,7 +937,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # Application definition for a configuration file of the paraprobe-nanochem tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -951,10 +951,10 @@ NXapm_paraprobe_nanochem_config(NXobject): # # Discretization and distributing of the ion point cloud on a 3D grid # to enable continuum-scale analyses. -# +# # By default, the tool computes a full kernel density estimation of decomposed # ions to create one discretized field for each element. -# +# # One delocalization task configures a parameter sweep with at least one # delocalization. The total number of runs depends on the number of # grid_resolution and kernel_variance values. For example, setting two grid_resolutions @@ -1127,25 +1127,25 @@ NXapm_paraprobe_nanochem_config(NXobject): # times an ion is to be counted. The tool performs a so-called atomic decomposition # of all iontypes, i.e. the tool analyses from how many atoms of each nuclide # or element respectively an (molecular) ion is built from. -# +# # Taking the hydroxonium H3O+ molecular ion as an example: # It contains hydrogen and oxygen atoms. The multiplicity of hydrogen # is three whereas that of oxygen is one. Therefore, the respective atomic decomposition # analysis prior to the iso-surface computation adds three hydrogen counts for each # H3O+ ion. -# +# # This is a practical solution which accepts that on the one hand not every bond is # broken during an atom probe experiment but also that ions may react further during # their flight to the detector. The exact details depend on the local field conditions, # quantum mechanics of possible electron transfer and thus the detailed trajectory # of the system and its electronic state. -# +# # The detection of molecular ions instead of always single atom ions only is the # reason that an atom probe experiment tells much about field evaporation physics # but also faces an inherent loss of information with respect to the detailed spatial # arrangement that is independent of other imprecisions such as effect of limited # accuracy of reconstruction protocols and their parameterization. -# +# # Unused values in each row of the matrix are nullified. # Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. # @@ -1217,11 +1217,11 @@ NXapm_paraprobe_nanochem_config(NXobject): # composition-normalized delocalization. Here, it is possible that the composition # increases towards the edge of the dataset because the quotient of two numbers # that 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, keep_edge_triangles instructs the tool to not remove triangles at the # edge of the dataset at the cost of bias. When using this keep_edge_triangles users # should understand that all features in contact with the edge of the dataset get usually @@ -1232,12 +1232,12 @@ NXapm_paraprobe_nanochem_config(NXobject): # of grain shapes via orientation microscopy from electron microscopy or X-ray # diffraction tomography. Features at the edge of the dataset may have not been # captured fully. -# +# # Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, # paraprobe-nanochem implements a complete pipeline to process features at the edge of the # dataset. Specifically, these are modelled and replaced with closed polyhedral objects using # an iterative mesh and hole-filling procedures with fairing operations. -# +# # The tool bookkeeps such objects separately to lead the decision whether or not to # consider these objects to the user. Users should be aware that results from fairing operations # should be compared to results from analyses where all objects at the edge @@ -1247,7 +1247,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # deliver statistically significant results for compositions, this does not necessarily mean that # same dataset will also yield statistically significant and insignificantly biased results for # 3D 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. # @@ -1260,7 +1260,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # The ion-to-surface distance that is used in the analyses of features to identify whether # these are laying inside the dataset or close to the surface (edge) of the dataset. -# +# # If an object has at least one ion with an ion-to-surface-distance below this threshold, # the object is considered close to the edge of the dataset. The tool uses a distance-based # approach to solve the in general complicated and involved treatment of computing @@ -1269,7 +1269,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # robustness issues as a consequence of which a mesh can be detected as being completely # inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost # touching only the edge (e.g. from inside). -# +# # Practically, humans would likely still 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 flexible. @@ -1280,11 +1280,12 @@ NXapm_paraprobe_nanochem_config(NXobject): # Iso-contour values. For each value, the tool computes an iso-surface and performs # subsequent analyses for each iso-surface. 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 +# # # # @@ -1292,7 +1293,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # Specifies if the tool should report the triangle soup which represents each triangle of the # iso-surface complex. The resulting set of triangles is colloquially referred to as a soup # because different sub-set may not be connected. -# +# # Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) # the triangle belongs. The clustering of triangles within the soup is performed with a # modified DBScan algorithm. @@ -1303,12 +1304,12 @@ NXapm_paraprobe_nanochem_config(NXobject): # 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 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 scandium-rich precipitates in aluminum alloys # which in reconstructions may appear as ellipsoids although they should be indeed almost spherical @@ -1320,7 +1321,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # 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 tiny sub-complexes # (e.g. small isolated tetrahedra). -# +# # These can be small tetrahedra/polyhedra about the center of a voxel of the support grid # on which marching cubes operates. Such objects may not contain an ion; especially when considering # that delocalization procedures smoothen the positions of the ions. Although these small objects are @@ -1341,7 +1342,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # 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). -# +# # Users should be aware that the choice of the algorithm to compute the bounding box can have an # effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D # is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms @@ -1353,7 +1354,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which # lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector # tool to infer if two objects share common ions, which is then understood as 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 and flat # face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of @@ -1361,7 +1362,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # might be so small or happening in the volume between two reconstructed ion positions. Consequently, # sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections # between objects. -# +# # 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 @@ -1382,7 +1383,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose # combinatorial analysis according to has_object returned 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 feature. # In most cases objects, precipitates in atom probe end up as open objects because they have been # clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account @@ -1429,7 +1430,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: # If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. # Otherwise, the ROI is assumed to make no edge contact. -# +# # Users should note that this approach does not work if the ROI is laying completely outside the dataset as also # in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant # provided constructions such as alpha shapes or alpha wrappings (such as paraprobe-surfacer does) about the @@ -1446,7 +1447,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # Use a principle component analysis (PCA) to mesh a single free-standing interface patch within # the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). -# +# # Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess # in cases when closed objects constructed from patches e.g. iso-surfaces are not available or # when there is no substantial or consistently oriented concentration gradients across an interface @@ -1454,7 +1455,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # within the point cloud is insufficient or when combined with interface_meshing based on ion density # traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ # and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). -# +# # Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations # paraprobe-nanochem uses inspection functionalities which detect potential geometric # inconsistencies or self-interactions of the evolved DCOM mesh. @@ -1550,11 +1551,11 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # How is the PCA initialized: -# +# # * 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>`_ creates a control_point_file that # can be parsed by paraprobe-parmsetup-nanochem to match the here required @@ -1631,7 +1632,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # 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 might be relocated. -# +# # The larger it is the DCOM radius in relation to the target_edge_length the more # likely it becomes that vertices will be relocated so substantially that triangle # self-intersections may occur. The tool detects these and stops in a controlled @@ -1660,21 +1661,21 @@ NXapm_paraprobe_nanochem_config(NXobject): # Analysis of one-dimensional profiles in ROIs placed in the dataset. # Such analyses are useful for quantifying interfacial excess or for # performing classical composition analyses. -# +# # The tool will test for each ROIs if it is completely embedded in the dataset. # Specifically, each such test evaluates if the ROI cuts at least one triangle # of the triangulated surface mesh that is referred to by surface. # If this is the case the ROI is marked as one close to the surface # and not analyzed further. Otherwise, the ROI is marked as one far # from the surface and processed further. -# +# # For each ROI the tool computes atomically decomposed profiles. # This means, molecular ions are split into nuclides as many times as # their respective multiplicity. For each processed ROI the tool stores # a sorted list of signed distance values to enable post-processing with # other software like e.g. reporter to perform classical # Krakauer/Seidman-style interfacial excess analyses. -# +# # Users should be aware that the latter intersection analysis is not # a volumetric intersection analysis. Given that the triangulated mesh # referred to in surface is not required to mesh neither a watertight diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index a6d4f8e839..11901df475 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -1170,7 +1170,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # Application definition for results files of the paraprobe-nanochem tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # @@ -1363,12 +1363,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -1408,13 +1408,14 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # The boundary conditions for each boundary: -# +# # 0 - undefined # 1 - open # 2 - periodic # 3 - mirror # 4 - von Neumann # 5 - Dirichlet +# # # # @@ -1427,10 +1428,10 @@ NXapm_paraprobe_nanochem_results(NXobject): # # The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces # will be computed. In commercial software so far there is no possibility to export this information. -# +# # If the intensity for all matches of the weighting_model are summarized name this NXdata instance # scalar_field_magn_total. -# +# # If the intensity is reported for each iontype one can avoid many subsequent # computations as individual intensities can be reinterpreted using a different weighting_model in # down-stream usage of the here reported values (e.g. with Python scripting). @@ -1586,12 +1587,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # An iso-surface is the boundary between two regions across which the magnitude of a # scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. -# +# # Instances should iso_surface as a name prefix. -# +# # For applications in atom probe microscopy, the location and shape of such a boundary (set) # is typically approximated by discretization - triangulation to be specific. -# +# # This yields a complex of not necessarily connected geometric primitives. # Paraprobe-nanochem approximates this complex with a soup of triangles. # @@ -1625,7 +1626,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # Positions of the vertices. -# +# # Users are encouraged to reduce the vertices to a unique set as this may # result in a more efficient storage of the geometry data. # It is also possible though to store the vertex positions naively in which @@ -1640,12 +1641,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -1678,10 +1679,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier how which specifically oriented normal to its # primitive each normal represents. -# +# # * 0 - undefined # * 1 - outer # * 2 - inner +# # # # @@ -1704,10 +1706,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier how which specifically oriented normal to its # primitive each normal represents. -# +# # * 0 - undefined # * 1 - outer # * 2 - inner +# # # # @@ -1792,9 +1795,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # This may yield a set of connected features whose individual surfaces are discretized # by a triangulated mesh each. Such volumetric features can be processed further using # paraprobe-nanochem using a workflow with at most two steps. -# +# # In the first step, the tool distinguishes three types of (v) i.e. volumetric features: -# +# # 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. # These objects were already watertight within the triangulated iso-surface. # 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated @@ -1803,11 +1806,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality # that are not transformable into proxies or for which no transformation into proxies was # instructed. -# +# # 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. -# +# # In the second step, the tool can be used to analyze the proximity of these objects to a # model of the surface (edge) of the dataset. # @@ -1862,13 +1865,14 @@ NXapm_paraprobe_nanochem_results(NXobject): # In all situations instances of the parent NXprocess group are returned with a very similar # information structuring and thus we here replace the template name FEATURE # with one of the following types feature-specific group names: -# +# # * objects, objects, irrespective their distance to the surface # * objects_close_to_edge, sub-set of v_feature_object close surface # * objects_far_from_edge, sub-set of v_feature_object not close to the surface # * proxies, proxies, irrespective their distance to the surface # * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface # * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface +# # # # @@ -2073,7 +2077,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # The triangle surface mesh representing the interface model. # Exported at state before or after the next DCOM step. -# +# # Instances should use mesh_state as a name prefix. # # @@ -2119,10 +2123,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier which details how specifically oriented the # face normal is with respect to its primitive (triangle): -# +# # * 0 - undefined # * 1 - outer # * 2 - inner +# # # # @@ -2147,10 +2152,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # Qualifier which details how specifically oriented the # face normal is with respect to its primitive (triangle): -# +# # * 0 - undefined # * 1 - outer # * 2 - inner +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 66fb973345..582d64035b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -145,7 +145,7 @@ NXapm_paraprobe_ranger_config(NXobject): # # # Application definition for a configuration file of the paraprobe-ranger tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 066a2d5912..cbc6e725c4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -138,7 +138,7 @@ NXapm_paraprobe_ranger_results(NXobject): # # # Application definition for results files of the paraprobe-ranger tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within # a certain (possibly complicated) selection of ions (based on their properties or location in the diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 393a8480de..50f9901b45 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -126,7 +126,7 @@ NXapm_paraprobe_selector_config(NXobject): # # # Application definition for a configuration file of the paraprobe-selector tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 5fd4a1305e..e1bd260d89 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -112,7 +112,7 @@ NXapm_paraprobe_selector_results(NXobject): # # # Application definition for results files of the paraprobe-selector tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions # are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 5b328f9afd..f513ec60b9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -315,7 +315,7 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # Application definition for a configuration file of the paraprobe-spatstat tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -365,10 +365,10 @@ NXapm_paraprobe_spatstat_config(NXobject): # of the dataset so that the ion can act as a source. This means that # an ROI is placed at the location of the ion and its neighbors are # analyzed how they contribute to the computed statistics. -# +# # The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a # microstructural feature an ROI is placed. -# +# # The threshold is useful to process the dataset such that ROIs do # not protrude out of the dataset as this would add bias. # @@ -398,7 +398,7 @@ NXapm_paraprobe_spatstat_config(NXobject): # 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 this feature_distance threshold is used in combination # with the edge_distance threshold when placing ROI about source ions. # @@ -476,25 +476,25 @@ NXapm_paraprobe_spatstat_config(NXobject): # 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 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index ae2b7ba33f..1f3a830410 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -200,7 +200,7 @@ NXapm_paraprobe_spatstat_results(NXobject): # # # Application definition for results files of the paraprobe-spatstat tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # @@ -226,7 +226,7 @@ NXapm_paraprobe_spatstat_results(NXobject): # 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 remain the same. -# +# # The order matches the iontypes array from a given ranging results # as it is specified in the configuration settings inside the specific # config_filename that was used for this paraprobe-spatstat analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index b31ed90ee8..5c7063d73b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -219,7 +219,7 @@ NXapm_paraprobe_surfacer_config(NXobject): # # # Application definition for a configuration file of the paraprobe-surfacer tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # @@ -301,7 +301,7 @@ NXapm_paraprobe_surfacer_config(NXobject): # # Specifies the method that is used to preprocess the point cloud # prior to the alpha-shape computation. -# +# # The option *default* specifies that no such filtering is applied. # The option *kuehbach* specifies that a Hoshen-Kopelman # percolation analysis is used to identify points that lie closer @@ -324,18 +324,18 @@ NXapm_paraprobe_surfacer_config(NXobject): # # # Specifies which method to use to define the alpha value. -# +# # The value *convex_hull_naive* is the default. The setting 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* instructs to tool to refine the # quality of the mesh resulting from *convex_hull_naive* # via triangle flipping and splitting. -# +# # 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 CGAL library to choose a # value which the library considers as to be an optimal value. # Details are defined in the respective section of the CGAL library diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index fd63a8dfd7..148e2bf41f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -277,7 +277,7 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # Application definition for results files of the paraprobe-surfacer tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # The purpose and need of the paraprobe-surfacer tool is the generation of meshed # representation of the surface of the the reconstructed volume (or a portion) of it @@ -298,11 +298,11 @@ NXapm_paraprobe_surfacer_results(NXobject): # 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. @@ -325,7 +325,7 @@ NXapm_paraprobe_surfacer_results(NXobject): # A bitmask which identifies exactly all those ions whose positions # were considered when defining the filtered point set from which # that alpha_complex instance was computed. -# +# # This window can be different to the window of the *point_set_wrapping* # parent group because irrelevant ions might have been filtered out in addition # to the window defined in *point_set_wrapping* to reduce e.g. computational diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index a9c92cd95f..95c5ac8d90 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -170,7 +170,7 @@ NXapm_paraprobe_tessellator_config(NXobject): # # # Application definition for a configuration file of the paraprobe-tessellator tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 297980acd1..7fcddcba3a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -318,7 +318,7 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # Application definition for results files of the paraprobe-tessellator tool. -# +# # This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 12d5ad59d1..69f201eda4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -116,21 +116,21 @@ NXapm_paraprobe_tool_common(NXobject): # # # Base class documenting the information common to tools of the paraprobe-toolbox. -# +# # The paraprobe-toolbox is a collection of open-source tools for performing # efficient analyses of point cloud data where each point can represent atoms or # (molecular) ions. A key application of the toolbox has been for research in the # field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): -# +# # * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ # * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ -# +# # The toolbox does not replace but complements existent software tools in this # research field. Given its capabilities of handling points as objects with # properties and enabling analyses of the spatial arrangement of and inter- # sections between geometric primitives, the software can equally be used # for analyzing data in Materials Science and Materials Engineering. -# +# # The common section can be used as a place to store e.g. organizational # metadata and contextualization of that analysis in a research data # management system. @@ -141,7 +141,7 @@ NXapm_paraprobe_tool_common(NXobject): # or whether this failed. Status is written to the results file after the # end_time beyond which point in time the tool must no longer compute # any further analysis results but exit. -# +# # Only when this status message is present and its value is `success`, # one should consider the results of the tool. In all other cases it might # be that the tool has terminated prematurely or another error occurred. @@ -196,7 +196,7 @@ NXapm_paraprobe_tool_common(NXobject): # 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: -# +# # * paraprobe # * lab # * specimen @@ -204,7 +204,7 @@ NXapm_paraprobe_tool_common(NXobject): # * 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 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 335e95eab1..0cfa37d3a8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -15,7 +15,7 @@ doc: | properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - + The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). @@ -98,7 +98,7 @@ NXapm_paraprobe_tool_config(NXobject): (NXmatch_filter): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fe35f744d4a24ba3b10c8201960ca744551b7a6067f968e7262aac712f2bddab +# 5b1e870ad6840ca73ed2b481cad11f2db20697da8de53c9e68785f4e7ec21a9e # # # # # # Number of vertices for each face. -# +# # Each entry represents the total number of vertices for that face, # irrespectively whether vertices are shared among faces or not. # @@ -256,7 +256,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # Number of edges for each face. -# +# # Each entry represents the total number of edges for that face, # irrespectively whether edges are shared across faces or not. # @@ -273,7 +273,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the vertices differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -282,7 +282,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the edges differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -291,7 +291,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the faces differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of NXcg_primitive for further details. # @@ -323,7 +323,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # Positions of the vertices. -# +# # Users are encouraged to reduce the vertices to a unique set as this may # result in more efficient storage. Alternatively, storing vertex positions naively # should be indicated with setting vertices_are_unique to False. @@ -347,12 +347,12 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # The faces are stored as a concatenated array of vertex identifier tuples. -# +# # 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -372,7 +372,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # If true, indicates that no edge is stored more than once. -# +# # Users are encouraged to consider using a half_edge_data_structure instead. # # @@ -384,10 +384,11 @@ NXcg_face_list_data_structure(NXcg_primitive): # # # 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_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index 7981225356..57049a24b2 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -174,7 +174,7 @@ NXcg_grid(NXcg_primitive): # # # Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. -# +# # Three-dimensional grids with cubic cells are if not the most frequently used # example of such grids. Numerical methods and models that use grids are used # in many cases in the natural sciences and engineering disciplines. Examples are @@ -184,7 +184,7 @@ NXcg_grid(NXcg_primitive): # # # Location of the origin of the grid. -# +# # Use the depends_on field that is inherited from the :ref:`NXcg_primitive` # class to specify the coordinate system in which the origin location is defined. # @@ -211,7 +211,7 @@ NXcg_grid(NXcg_primitive): # # # 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 @@ -254,7 +254,7 @@ NXcg_grid(NXcg_primitive): # # # Number of boundaries distinguished -# +# # Most grids discretize a cubic or cuboidal region. In this case # six sides can be distinguished, each making an own boundary. # @@ -271,13 +271,14 @@ NXcg_grid(NXcg_primitive): # # # The boundary conditions for each boundary: -# +# # 0 - undefined # 1 - open # 2 - periodic # 3 - mirror # 4 - von Neumann # 5 - Dirichlet +# # # # @@ -288,17 +289,17 @@ NXcg_grid(NXcg_primitive): # Details about the computational geometry method and implementation # used for discretizing internal surfaces as e.g. obtained with marching methods, # like marching squares or marching cubes. -# +# # Documenting which specific version was used helps with understanding how # robust the results are with respect to the topology of the triangulation. # 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 ideally be an identifier of a program. # If not possible, an identifier for a paper, technical report, or free-text # description can be used instead. diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index 1f5a471670..593e1e47a5 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -196,11 +196,11 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # # Computational geometry 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. The data structure is also # known as a doubly connected edge list. -# +# # Indices can be used as identifier and thus names for individual instances. # # @@ -212,7 +212,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # # Number of vertices for each face. -# +# # Each entry represents the total number of vertices for that face, # irrespectively whether vertices are shared among faces or not. # @@ -223,7 +223,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # # Number of edges for each face. -# +# # Each entry represents the total number of edges for that face, # irrespectively whether edges are shared across faces or not. # @@ -235,7 +235,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the vertices differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -244,7 +244,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the edges differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -253,7 +253,7 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # Integer offset whereby the identifier of the first member # of the faces differs from zero. -# +# # Identifier can be defined explicitly or implicitly. # Inspect the definition of :ref:`NXcg_primitive` for further details. # @@ -329,11 +329,11 @@ NXcg_half_edge_data_structure(NXcg_primitive): # # 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_polygon.yaml b/contributed_definitions/nyaml/NXcg_polygon.yaml index bc715c1c7a..efc9f6d00f 100644 --- a/contributed_definitions/nyaml/NXcg_polygon.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon.yaml @@ -141,24 +141,24 @@ NXcg_polygon(NXcg_primitive): # # # Computational geometry description of a set of polygons in Euclidean space. -# +# # Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed # polyhedra. Even more general complexes can be thought of. An example are the # so-called piecewise-linear complexes used in the TetGen library. -# +# # As these complexes 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 to describe such even more complex primitives instead @@ -178,14 +178,14 @@ NXcg_polygon(NXcg_primitive): # # # Individual storage of the mesh of each polygon. -# +# # Instances should use polygon as a name prefix. # # # # # Individual storage of each polygon as a graph. -# +# # Instances should use polygon_half_edge as a name prefix. # # @@ -213,10 +213,11 @@ NXcg_polygon(NXcg_primitive): # # # Curvature type: -# +# # * 0 - unspecified, # * 1 - convex, # * 2 - concave +# # # # diff --git a/contributed_definitions/nyaml/NXcg_polyhedron.yaml b/contributed_definitions/nyaml/NXcg_polyhedron.yaml index 49ea708c61..0cf11153ff 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron.yaml @@ -134,11 +134,11 @@ NXcg_polyhedron(NXcg_primitive): # # # Computational geometry description of a set of polyhedra in Euclidean space. -# +# # Polyhedra or so-called cells (especially in the convex of tessellations) are # constructed from polygon meshes. Polyhedra may make contact to allow a usage # of this base class for a description of tessellations. -# +# # For the description of more complicated manifolds and especially for polyhedra # with holes, users are advised to check if their particular needs are described # by creating customized instances of an :ref:`NXcg_polygon`. @@ -184,14 +184,14 @@ NXcg_polyhedron(NXcg_primitive): # # # Individual storage of each polyhedron. -# +# # Instances should use polyhedron as a name prefix. # # # # # Individual storage of each polygon as a graph. -# +# # Instances should use cluster_analysis as a name prefix. # # diff --git a/contributed_definitions/nyaml/NXcg_polyline.yaml b/contributed_definitions/nyaml/NXcg_polyline.yaml index fffdef70d5..e8811f4c55 100644 --- a/contributed_definitions/nyaml/NXcg_polyline.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline.yaml @@ -149,7 +149,7 @@ NXcg_polyline(NXcg_primitive): # # # Computational geometry description of a set of polylines. -# +# # 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 traversal along the polyline when @@ -188,7 +188,7 @@ NXcg_polyline(NXcg_primitive): # # # Positions of the vertices which support the members of the polyline set. -# +# # Users are encouraged to reduce the vertices to unique positions and vertices # as this often supports with storing geometry data more efficiently. # It is also possible though to store the vertex positions naively @@ -212,17 +212,17 @@ NXcg_polyline(NXcg_primitive): # # # Sequence of identifier for vertices how they build each polyline. -# +# # A trivial example is a set with two polylines with three vertices each. # If the polylines meet at a vertex (assume for example that the second vertex # is shared and marking the junction between the two polylines), it is possible # that there are only five unique positions. This suggests to store five # unique vertices. -# +# # A non-trivial example is a set with several polylines. Assume that each # has a different number of vertices. The array stores the identifier of # the vertices in the sequence how the polylines are visited: -# +# # The first entry is the identifier of the first vertex of the first polyline, # followed by the second vertex of the first polyline, until the last vertex # of the first polyline. diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml index 1e4e97b56d..e124adbf70 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -123,36 +123,36 @@ NXcs_filter_boolean_mask(NXobject): # # # Base class for packing and unpacking booleans. -# +# # This base class bookkeeps metadata to inform software about necessary modulo # operations to decode e.g. set membership of objects in sets which are encoded # as a packed array of boolean values. -# +# # One use case is processing of object sets (e.g. point cloud data). If e.g. a # spatial filter has been applied to a set of points we may wish to store # document efficiently which points were analyzed. Array of boolean values # is one option to achieve this. A value is true if the point is included. # The resulting boolean array will be filled with true and false values # in a manner that is often arbitrary and in general case-dependent. -# +# # Especially when the number of points is large, for instance several thousands # or more, some situations can be more efficiently stored if one does not store # the boolean array but just lists the identifiers of the points taken. -# +# # For example, if within a set of 1000 points only one point is included, it would # take (naively) 4000 bits to store the array but only 32 bits to store e.g. the # ID of the single point that is taken. 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 in that # they store compact representation of set memberships. -# +# # This base class can deal with the situation when the number of objects # is not an integer multiple of the bit depth used for storing the states. # # # # Possibility to refer to which set this mask applies. -# +# # If depends_on is not provided, it is assumed that the mask # applies to its direct parent. # diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index ddd58462cf..3292b657f9 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -297,12 +297,13 @@ NXem_calorimetry(NXobject): # # # Application definition for minimal example in-situ calorimetry. -# +# # TODO: -# +# # * What is the technique about. # * General context. # * Literature references. +# # # # @@ -351,7 +352,7 @@ NXem_calorimetry(NXobject): # contained in the specimen. If the specimen substance has multiple # components, all elements from each component must be included in # `atom_types`. -# +# # The purpose of the field is to offer research data management systems an # opportunity to parse the relevant elements without having to interpret # these from the resources. @@ -365,7 +366,7 @@ NXem_calorimetry(NXobject): # # Reference to the resource which stores acquired pattern from the # experiment or simulation that are analyzed in this workflow. -# +# # Can refer to the original EMD or MRC files or the parsed NXem # in RDM e.g. NOMAD OASIS. # @@ -401,7 +402,7 @@ NXem_calorimetry(NXobject): # with which delta_time can be converted in timestamp. # The reference timestamp is defined as the time when the # actuator started acting on the sample. -# +# # Time differences to this timestamp when correlated signals such # as diffraction pattern matching with a specific state of the sample # (e.g. obtained temperature via the actuator) are reported through @@ -416,7 +417,7 @@ NXem_calorimetry(NXobject): # # # Time difference to start_time. -# +# # Collecting diffraction pattern also takes some time. # It is assumed that the acquisition time for each pattern is # substantial shorter than the time it takes the actuator to @@ -483,9 +484,10 @@ NXem_calorimetry(NXobject): # # # The integrated intensities: -# +# # * result_with_background # * result_without_background +# # # # diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml index 470414f85c..6259f46f7d 100644 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -27,7 +27,7 @@ NXlab_sample_mounting(NXobject): mounting_machine(NXfabrication): vendor: model: - identifier: + serial_number: exists: recommended mounting_method: doc: | @@ -55,7 +55,7 @@ NXlab_sample_mounting(NXobject): # key question is which steps has the sample experienced? # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b9d170c9b46c62975977f356527c80694cffe0dfd43fa54139cb712620ce6882 +# 4572e5c48086780e3988c719073d9c4c8782e28adae5590556ebb80ca01fee02 # # # diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml index 99c2c2bd40..18e5d50e8b 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -159,11 +159,11 @@ NXsimilarity_grouping(NXobject): # # # Base class to store results obtained from applying a similarity grouping (clustering) algorithm. -# +# # Similarity grouping algorithms are segmentation or machine learning algorithms for # partitioning the members of a set of objects (e.g. geometric primitives) into # (sub-)groups aka features of different kind/type. A plethora of algorithms exists. -# +# # This base class considers metadata and results of having a similarity grouping # algorithm applied to a set in which objects are either categorized as noise # or belonging to a cluster, i.e. members of a cluster. @@ -194,7 +194,7 @@ NXsimilarity_grouping(NXobject): # # # Which numerical index is the first to be used to label a feature. -# +# # The value should be chosen in such a way that special values can be resolved: # * index_offset - 1 indicates that an object belongs to no cluster. # * index_offset - 2 indicates that an object belongs to the noise category. From 8fb08ea0ed0e0261cde6e44c5e097aef0237aa13 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Mar 2025 21:50:31 +0100 Subject: [PATCH 04/57] A few more whitespaces --- .../NXapm_compositionspace_results.nxdl.xml | 8 ++++---- .../NXmicrostructure_imm_config.nxdl.xml | 4 ++-- .../NXmicrostructure_score_config.nxdl.xml | 8 ++++---- .../nyaml/NXapm_compositionspace_results.yaml | 8 ++++---- .../nyaml/NXmicrostructure_imm_config.yaml | 4 ++-- .../nyaml/NXmicrostructure_score_config.yaml | 8 ++++---- 6 files changed, 20 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 5795caed1c..d7b6a1bddf 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -44,9 +44,9 @@ Application definition for results of the CompositionSpace tool used in atom probe. - + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the CompositionSpace software using NeXus. @@ -100,7 +100,7 @@ for if desired all the dependencies and libraries--> contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in `atom_types`. - + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources pointed to by identifier_parent or walk through @@ -113,7 +113,7 @@ for if desired all the dependencies and libraries--> Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that was ranged for each ion. - + Using a discretization grid that is larger than the average distance between reconstructed ion positions reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods used in atom probe for characterizing microstructural features that use the ion position data directly. diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index 127e776f05..ac239d0c35 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -42,12 +42,12 @@ Application definition for the configuration of the legacy (micro)structure generator developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index b5061cd9df..ec38c05beb 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -75,7 +75,7 @@ * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ - + @@ -191,7 +191,7 @@ SecondOrderThermalExpCoeff--> * poisson_voronoi, a discretized poisson voronoi * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. - + @@ -294,7 +294,7 @@ SecondOrderThermalExpCoeff--> * csr, complete spatial randomness * custom, implementation-specific * gb, nuclei placed at grain boundaries - + @@ -316,7 +316,7 @@ SecondOrderThermalExpCoeff--> * ensemble, picking randomly one from ensemble/bunge_euler * random, picking randomly on the SO3 * damask, picking based on information provided in deformation/damask - + diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 5388c238ec..f6f358b8ed 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -356,9 +356,9 @@ NXapm_compositionspace_results(NXobject): # # # Application definition for results of the CompositionSpace tool used in atom probe. -# +# # * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ -# +# # This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure # use case IUC09 that explores how to improve the organization and results storage of the # CompositionSpace software using NeXus. @@ -412,7 +412,7 @@ NXapm_compositionspace_results(NXobject): # contained in the specimen. If the specimen substance has multiple # components, all elements from each component must be included in # `atom_types`. -# +# # The purpose of the field is to offer research data management systems an # opportunity to parse the relevant elements without having to interpret # these from the resources pointed to by identifier_parent or walk through @@ -425,7 +425,7 @@ NXapm_compositionspace_results(NXobject): # Step during which the point cloud is discretized to compute element-specific composition fields. # Iontypes are atomically decomposed to correctly account for the multiplicity of each element that # was ranged for each ion. -# +# # Using a discretization grid that is larger than the average distance between reconstructed ion positions # reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods # used in atom probe for characterizing microstructural features that use the ion position data directly. diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index dbdfba5d12..bd66cbcfde 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -221,12 +221,12 @@ NXmicrostructure_imm_config(NXobject): # # Application definition for the configuration of the legacy (micro)structure generator # developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# +# # * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ # * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ # * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ # * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# +# # The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. # Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. # Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 52a219f7e3..aeb34c4b94 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -621,7 +621,7 @@ NXmicrostructure_score_config(NXobject): # # * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ # * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ -# +# # # # @@ -737,7 +737,7 @@ NXmicrostructure_score_config(NXobject): # * poisson_voronoi, a discretized poisson voronoi # * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map # * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. -# +# # # # @@ -840,7 +840,7 @@ NXmicrostructure_score_config(NXobject): # * csr, complete spatial randomness # * custom, implementation-specific # * gb, nuclei placed at grain boundaries -# +# # # # @@ -862,7 +862,7 @@ NXmicrostructure_score_config(NXobject): # * ensemble, picking randomly one from ensemble/bunge_euler # * random, picking randomly on the SO3 # * damask, picking based on information provided in deformation/damask -# +# # # # From 78d97cdd2601e5f7e5f9ba7bec4eaafa60e50ee9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Mar 2025 23:47:19 +0100 Subject: [PATCH 05/57] phase_identifier --- contributed_definitions/NXphase.nxdl.xml | 2 +- contributed_definitions/nyaml/NXphase.yaml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXphase.nxdl.xml b/contributed_definitions/NXphase.nxdl.xml index 61f5e2032e..f75fa637d8 100644 --- a/contributed_definitions/NXphase.nxdl.xml +++ b/contributed_definitions/NXphase.nxdl.xml @@ -27,7 +27,7 @@ Instances of phases can be crystalline. - + Identifier for each phase. diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml index c047016bc6..45980b33ea 100644 --- a/contributed_definitions/nyaml/NXphase.yaml +++ b/contributed_definitions/nyaml/NXphase.yaml @@ -5,7 +5,7 @@ doc: | Instances of phases can be crystalline. type: group NXphase(NXobject): - phase_identifier(NX_INT): + phase_id(NX_INT): unit: NX_UNITLESS doc: | Identifier for each phase. @@ -45,7 +45,7 @@ NXphase(NXobject): Instance names should use odf as a prefix. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fe2c45a22774ad41e780447e397a12ce1afcdd58e5a776514d651cd29bb0e716 +# 8270c365f2d0f112d6b98043c78b7edc77913f55c1f70ab4c1a389192f12c0bd # # # + + + TODO + + + + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index d7b6a1bddf..84271af544 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -79,20 +79,19 @@ for if desired all the dependencies and libraries--> - + Contextualize back to the specimen from which the dataset was collected that was here analyzed with CompositionSpace tool. - + - A qualifier whether the specimen is a real one or a virtual one. + True, if the specimen that the reconstructed dataset + describes is a simulated one. + False, if the specimen that the reconstructed dataset + describes is a real one. - - - - diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 1299cef9bf..0dfcb1dd08 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -136,8 +136,20 @@ NXapm_compositionspace_config(NXobject): min_samples(NX_UINT): unit: NX_UNITLESS doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core - point. + The number of voxels in a neighborhood for a + voxel to be considered as a core point. + meshing(NXprocess): + doc: | + TODO + distance_cut(NX_NUMBER): + doc: | + TODO + # units: NX_ANY + + normal_end_length(NX_NUMBER): + doc: | + TODO + # units: NX_ANY # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # aab59ee3d2b3ae802fde9bdc282c5679a8a42b98721096d8a915d5f46354f74a diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index f6f358b8ed..fe21ec0e18 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -52,14 +52,17 @@ NXapm_compositionspace_results(NXobject): (NXuser): exists: optional specimen(NXsample): + exists: recommended doc: | Contextualize back to the specimen from which the dataset was collected that was here analyzed with CompositionSpace tool. - type(NX_CHAR): + is_simulation(NX_BOOLEAN): doc: | - A qualifier whether the specimen is a real one or a virtual one. - enumeration: [experiment, simulation] + True, if the specimen that the reconstructed dataset + describes is a simulated one. + False, if the specimen that the reconstructed dataset + describes is a real one. atom_types(NX_CHAR): doc: | List of comma-separated elements from the periodic table that are From e27f2969f2f8adc2fca321772458219385ce5cf4 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 4 Apr 2025 18:23:32 +0200 Subject: [PATCH 07/57] Updates on NXmicrostructure, fine tuning of symbols, and concepts surplus proofreading --- .../NXmicrostructure.nxdl.xml | 296 +++++---- .../NXmicrostructure_odf.nxdl.xml | 4 +- .../nyaml/NXapm_compositionspace_config.yaml | 30 +- .../nyaml/NXapm_compositionspace_results.yaml | 15 +- .../nyaml/NXmicrostructure.yaml | 566 +++++++++++------- .../nyaml/NXmicrostructure_odf.yaml | 10 +- 6 files changed, 583 insertions(+), 338 deletions(-) diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index efca4d731c..e5b8a8bc9a 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -27,6 +27,26 @@ The symbols used in the schema to specify e.g. dimensions of arrays. + + + The number of crystals or their projections + + + + + The number of interfaces or their projections + + + + + The number of triple junctions or their projections + + + + + The number of quadruple junctions or their projections + + @@ -101,58 +121,83 @@ The number of line defects.--> Whether one uses a continuum or atomic scale description of materials, these are always a model only of the true internal structure of a material. Such models are useful as they enable a coarse-graining and categorizing of properties and representational aspects from which measured or simulated descriptions - can be correlated with properties, i.e. descriptor values. + can be correlated with properties, i.e. descriptor values. The base class here can be used to describe + the structural aspect of a region-of-interest for a specimen that was investigated or a computer + simulation that was performed for a virtual specimen. - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated + Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, + the characterized microstructure may not turn out to be the same structure as of the untreated sample from which the region-of-interests on the specimen were sampled. Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually - always sample this evolution. Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. Often materials are characterized only for - specific states or via sampling coarsely in time relative to the timescale at which the - physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. + always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation + (projection) of the characterized material volume. Often materials are characterized only for specific states + or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. + This is typically a compromise between the research questions and technical surplus practical limitations. - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. - A key challenge with the description of representations and properties of microstructural features is that - features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with intuitive naming conventions using flat property lists. - For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation - of such dictionaries in the literature and the metadata section of public data repositories. + The term microstructural feature covers here crystals and all sorts of crystal defects within the material + (interfaces, triple junctions, dislocations, pores, etc.). + A key challenge with the description of representations and properties of such microstructural features is that + they can be represented and view as features with different dimensionality. Furthermore, combinations of features of + different dimensionality are frequently expected to be documented with intuitive naming conventions when + flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based + on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. NXmicrostructure is an attempt to standardize these descriptions stronger. - The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in - three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. - Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, - which gives typically rise to a plethora of configurations of which some yield useful properties. + For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and + junctions of different types of crystal defects. The term grain describes a contiguous region of material that is + delineated by interphases (phase or grain boundaries). With its origin motivated by light optical microscopy though + a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. + In this base class we use the term and respective group crystals though for single crystals and grains. + The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume + that the internal structure of these grains can be described with homogenized effective properties. + If alternatively the individual structural crystalline or features of this grain should be distinguished + it is useful to instantiate these as individual instances of crystals. + + Grain boundaries and phase boundaries are two main categories of interfaces. + A grain boundary delineates two regions with similar crystal structure and phase but different orientation. + A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically + but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two + phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments + but considers that atomic segregation is an equally important structural aspect to consider when classifying grain + boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties + is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and + `A. Sutton and R. W. Baluffi Interfaces in Crystalline Materials`_. + + Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. + Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, + or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material + properties or affect material properties. Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional - description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, - shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of - in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three - adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that - along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. + description such as a triple line or a triple point as the projection of a line. Therefore, different representations can + be used to describe the location, shape, and structure of such defect. + + This base class provides definitions for crystals, grains, interphases, triple junctions, and quadruple junctions thus covering, + volumetric, patch, line, and point like features that can serve as examples for future extension. - It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the - typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, - these are crystals, interfaces, triple lines, quadruple junctions. + As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable + objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations + as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- + triple-line junctions, likewise dislocations form own junctions. - The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ - and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. + The description took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ + and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers - for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. + for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. - Discouraged free-text field for leaving comments. + Discouraged free-text field for leaving comments @@ -221,6 +266,9 @@ the idea is we may wish to run as many grain reconstructions as we want and add + @@ -228,17 +276,33 @@ the idea is we may wish to run as many grain reconstructions as we want and add (NXcsg): (NXcontinuous_function): examples for specific frequently discussed microstructural features--> - + The chemical composition of this microstructure (region). - + + + + Different (thermodynamic) phases can be distinguished for the region-of- + interest. + + + + First identifier whereby to identify phases implicitly. + + + + + Instances should use phase as a prefix. + + + One- or two-dimensional projections, or three-dimensional representations of crystals. @@ -260,8 +324,8 @@ examples for specific frequently discussed microstructural features--> * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions - (like in computer simulations or 3D experiments) + * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. @@ -280,7 +344,7 @@ examples for specific frequently discussed microstructural features--> Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - + First identifier whereby to identify crystals implicitly. @@ -290,30 +354,27 @@ examples for specific frequently discussed microstructural features--> Identifier whereby to identify each crystal explicitly. - + - - - First identifier whereby to identify phases implicitly. - - Identifier whereby to identify phase for each crystal explicitly. - + - - + + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the feature makes contact with the edge of the ROI. + False, if the feature does not make contact with the edge of the ROI. - + @@ -323,7 +384,7 @@ examples for specific frequently discussed microstructural features--> average disorientation of that crystal. - + @@ -331,7 +392,7 @@ examples for specific frequently discussed microstructural features--> Length of each crystal - + @@ -339,7 +400,7 @@ examples for specific frequently discussed microstructural features--> Area of each crystal. - + @@ -347,9 +408,14 @@ examples for specific frequently discussed microstructural features--> Volume of each crystal - + + + + Possibility to store the mean orientation of the grain. + + @@ -359,6 +425,14 @@ examples for specific frequently discussed microstructural features--> An example for a surface defect. Most important are interfaces such as grain and phase boundaries but factually interfaces also exist between the environment and crystals exposed at the surface of the specimen or internal surfaces like between crystals, cracks, or pores. + + Interfaces are typically reported as discretized features. For interface projections on the 2D plane + these are most frequently polyline segments. For interface patches in 3D these are most frequently + triangulations. Descriptions with continuous functions are seldom used unless simplified configurations + are studied in modeling and theoretical studies. + + When using discretizations the individual interface segments need to be distinguished from the interfaces + themselves. Consequently, there are two sets of indices. @@ -366,7 +440,7 @@ examples for specific frequently discussed microstructural features--> * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. @@ -377,7 +451,7 @@ examples for specific frequently discussed microstructural features--> How many interfaces are distinguished. - + First identifier whereby to identify interfaces implicitly. @@ -389,7 +463,7 @@ examples for specific frequently discussed microstructural features--> An array with as many entries as interfaces or their projections. - + @@ -400,7 +474,7 @@ examples for specific frequently discussed microstructural features--> An array with as many pairs as interfaces or their projections. - + @@ -416,7 +490,7 @@ examples for specific frequently discussed microstructural features--> An array with as many pairs as interfaces or their projections. - + @@ -429,29 +503,29 @@ examples for specific frequently discussed microstructural features--> Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional - projections of these as those typically measured in electron microscopy. - In the case of a two-dimensional projection interfaces are interface traces and hence - they have two terminating junctions while in reality the interface is a surface patch - that is bounded by several triple lines. + projections. The latter situation applies typically for characterization with electron + microscopy. + + In the case of a two-dimensional projection interfaces are interface traces. These have + two terminating junctions. In three dimensions though the interface is a surface patch + that is bounded by multiple triple lines. Number of triple_junctions adjoining each interface. This array resolves the number of values along the second dimension for the field indices_triple_junctions. - - + + Set of pairs of indices_triple_junction for each interface. - An array with as many tuples along the first dimension i - as interfaces or their projections. - An array with as many values + An array with as many tuples of pairs to describe + all junctions about all interfaces. - @@ -460,13 +534,13 @@ examples for specific frequently discussed microstructural features--> - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the interface makes contact with the edge of the ROI. + False, if the interface does not make contact with the edge of the ROI. - + @@ -474,7 +548,7 @@ examples for specific frequently discussed microstructural features--> Gibbs free surface energy for each interface. - + @@ -482,7 +556,7 @@ examples for specific frequently discussed microstructural features--> Non-intrinsic mobility of each interface. - + @@ -493,7 +567,7 @@ examples for specific frequently discussed microstructural features--> polyline segments whereby the interface is discretized. - + @@ -501,7 +575,7 @@ examples for specific frequently discussed microstructural features--> The surface area of all interfaces. - + @@ -532,7 +606,7 @@ examples for specific frequently discussed microstructural features--> Number of triple junctions. - + First identifier to identify triple junctions implicitly. @@ -542,7 +616,7 @@ examples for specific frequently discussed microstructural features--> Identifier to identify each triple junction explicitly. - + junction. - + @@ -561,12 +635,12 @@ example i) triple points as projections of triple lines have locations--> - + Explicit positions. - + @@ -576,7 +650,7 @@ example i) triple points as projections of triple lines have locations--> triple junction. - + @@ -587,7 +661,7 @@ example i) triple points as projections of triple lines have locations--> triple junction. - + @@ -603,7 +677,7 @@ example i) triple points as projections of triple lines have locations--> each triple junction. - + @@ -614,13 +688,13 @@ example i) triple points as projections of triple lines have locations--> - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the triple line makes contact with the edge of the ROI. + False, if the triple line does not make contact with the edge of the ROI. - + @@ -628,7 +702,7 @@ EXAMPLES FOR DESCRIPTOR VALUES--> Specific line energy of each triple junction - + @@ -636,7 +710,7 @@ EXAMPLES FOR DESCRIPTOR VALUES--> Non-intrinsic mobility of each triple junction. - + @@ -647,15 +721,17 @@ EXAMPLES FOR DESCRIPTOR VALUES--> polyline segments whereby the junction is discretized. - + - The volume of the each triple junction + The volume about each triple junction. + + Respective cut-off criteria need to be specified. - + @@ -663,14 +739,20 @@ EXAMPLES FOR DESCRIPTOR VALUES--> Quadruple junctions as a region where four crystals meet. - An example for a point defect. + An example for a point (like) defect. + + Thermodynamically such junctions can be unstable. + Specifically when discretizations are used in simulations + that do not address the thermodynamics of and splitting characteristics + of junctions in cases when more than four crystals meet, it is possible + that so-called higher-order junctions are observed. Reference to an instance of: * :ref:`NXcg_point` - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks @@ -678,7 +760,7 @@ EXAMPLES FOR DESCRIPTOR VALUES--> Number of quadruple junctions. - + First identifier to identify quadruple junctions implicitly. @@ -699,7 +781,7 @@ example i) quadruple point locations explicitly--> junction. - + @@ -707,13 +789,13 @@ example i) quadruple point locations explicitly--> - + Explicit positions. - - + + @@ -723,7 +805,7 @@ example i) quadruple point locations explicitly--> junction. - + @@ -739,7 +821,7 @@ example i) quadruple point locations explicitly--> junction. - + @@ -756,7 +838,7 @@ example i) quadruple point locations explicitly--> each quadruple junction. - + @@ -773,7 +855,7 @@ example i) quadruple point locations explicitly--> each quadruple junction. - + @@ -784,13 +866,13 @@ example i) quadruple point locations explicitly--> - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the junction makes contact with the edge of the ROI. + True, if the junction does not make contact with the edge of the ROI. - + @@ -798,7 +880,7 @@ example i) quadruple point locations explicitly--> Energy of the quadruple_junction as a defect. - + @@ -806,7 +888,7 @@ example i) quadruple point locations explicitly--> Non-intrinsic mobility of each quadruple_junction. - + diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index f3541c3f1b..770dac2740 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -141,7 +141,7 @@ - The ODF intensity values (weights) as sampled with a software + The ODF intensity values (weights) as sampled with a software. @@ -174,7 +174,7 @@ This is one example of typical default plots used in the texture community in materials engineering. - Mind that when parameterized using Euler angles the orientation space is a distorted space. + Mind that the orientation space is a distorted space when it using an Euler angle parameterization. Therefore, equivalent orientations show intensity contributions in eventually multiple locations. +# +# +# TODO +# +# +# # # +# # diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index fe21ec0e18..2966783e6d 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -312,7 +312,7 @@ NXapm_compositionspace_results(NXobject): total_elapsed_time(NX_NUMBER): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60ae27662203a3ce6017f6d4d8edf21ecca9ad00c312d50c594d06e684a6dd08 +# da836d85361efa07431ace1a861fa56174dfc0a1eee62709c0a770923ed9d7dd # # # # -# +# # # Contextualize back to the specimen from which the # dataset was collected that was here analyzed with # CompositionSpace tool. # -# +# # -# A qualifier whether the specimen is a real one or a virtual one. +# True, if the specimen that the reconstructed dataset +# describes is a simulated one. +# False, if the specimen that the reconstructed dataset +# describes is a real one. # -# -# -# -# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index bc23e0b322..c33081b10a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -5,48 +5,73 @@ doc: | Whether one uses a continuum or atomic scale description of materials, these are always a model only of the true internal structure of a material. Such models are useful as they enable a coarse-graining and categorizing of properties and representational aspects from which measured or simulated descriptions - can be correlated with properties, i.e. descriptor values. + can be correlated with properties, i.e. descriptor values. The base class here can be used to describe + the structural aspect of a region-of-interest for a specimen that was investigated or a computer + simulation that was performed for a virtual specimen. - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated + Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, + the characterized microstructure may not turn out to be the same structure as of the untreated sample from which the region-of-interests on the specimen were sampled. Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually - always sample this evolution. Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. Often materials are characterized only for - specific states or via sampling coarsely in time relative to the timescale at which the - physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. + always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation + (projection) of the characterized material volume. Often materials are characterized only for specific states + or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. + This is typically a compromise between the research questions and technical surplus practical limitations. - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. - A key challenge with the description of representations and properties of microstructural features is that - features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with intuitive naming conventions using flat property lists. - For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation - of such dictionaries in the literature and the metadata section of public data repositories. + The term microstructural feature covers here crystals and all sorts of crystal defects within the material + (interfaces, triple junctions, dislocations, pores, etc.). + A key challenge with the description of representations and properties of such microstructural features is that + they can be represented and view as features with different dimensionality. Furthermore, combinations of features of + different dimensionality are frequently expected to be documented with intuitive naming conventions when + flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based + on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. NXmicrostructure is an attempt to standardize these descriptions stronger. - The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in - three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. - Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, - which gives typically rise to a plethora of configurations of which some yield useful properties. + For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and + junctions of different types of crystal defects. The term grain describes a contiguous region of material that is + delineated by interphases (phase or grain boundaries). With its origin motivated by light optical microscopy though + a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. + In this base class we use the term and respective group crystals though for single crystals and grains. + The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume + that the internal structure of these grains can be described with homogenized effective properties. + If alternatively the individual structural crystalline or features of this grain should be distinguished + it is useful to instantiate these as individual instances of crystals. + + Grain boundaries and phase boundaries are two main categories of interfaces. + A grain boundary delineates two regions with similar crystal structure and phase but different orientation. + A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically + but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two + phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments + but considers that atomic segregation is an equally important structural aspect to consider when classifying grain + boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties + is provided in e.g. `W. Bollmann `_ and + `A. Sutton and R. W. Baluffi Interfaces in Crystalline Materials`_. + + Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. + Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, + or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material + properties or affect material properties. Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional - description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, - shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of - in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three - adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that - along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. + description such as a triple line or a triple point as the projection of a line. Therefore, different representations can + be used to describe the location, shape, and structure of such defect. - It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the - typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, - these are crystals, interfaces, triple lines, quadruple junctions. + This base class provides definitions for crystals, grains, interphases, triple junctions, and quadruple junctions thus covering, + volumetric, patch, line, and point like features that can serve as examples for future extension. - The description attempt here took inspiration from `E. E. Underwood `_ - and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. + As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable + objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations + as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- + triple-line junctions, likewise dislocations form own junctions. + + The description took inspiration from `E. E. Underwood `_ + and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers @@ -56,6 +81,14 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + n_c: | + The number of crystals or their projections + n_i: | + The number of interfaces or their projections + n_tj: | + The number of triple junctions or their projections + n_qj: | + The number of quadruple junctions or their projections # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material n_c_one: | @@ -101,7 +134,7 @@ NXmicrostructure(NXobject): # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed comment(NX_CHAR): doc: | - Discouraged free-text field for leaving comments. + Discouraged free-text field for leaving comments date(NX_DATE_TIME): doc: | ISO8601 with offset to local time zone included when a timestamp is required. @@ -149,6 +182,10 @@ NXmicrostructure(NXobject): (NXcg_grid): (NXcg_point): (NXcg_polyline): + + # \@use_these(NX_CHAR): + # doc: | + # The specific identifiers whereby to resolve ambiguities. (NXcg_triangle): (NXcg_polygon): (NXcg_polyhedron): @@ -158,16 +195,25 @@ NXmicrostructure(NXobject): # (NXcontinuous_function): # examples for specific frequently discussed microstructural features chemical_composition(NXchemical_composition): - exists: optional doc: | The chemical composition of this microstructure (region). normalization(NX_CHAR): ELEMENT(NXatom): - exists: ['min', '1', 'max', '118'] nameType: any chemical_symbol(NX_CHAR): composition(NX_FLOAT): composition_error(NX_FLOAT): + phases(NXobject): + doc: | + Different (thermodynamic) phases can be distinguished for the region-of- + interest. + index_offset(NX_INT): + unit: NX_UNITLESS + doc: | + First identifier whereby to identify phases implicitly. + (NXphase): + doc: | + Instances should use phase as a prefix. crystals(NXobject): doc: | One- or two-dimensional projections, or three-dimensional representations of crystals. @@ -189,8 +235,8 @@ NXmicrostructure(NXobject): * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions - (like in computer simulations or 3D experiments) + * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. number_of_crystals(NX_UINT): @@ -205,7 +251,7 @@ NXmicrostructure(NXobject): How many phases are distinguished. Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - index_offset_crystal(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | First identifier whereby to identify crystals implicitly. @@ -214,25 +260,23 @@ NXmicrostructure(NXobject): doc: | Identifier whereby to identify each crystal explicitly. dimensions: - dim: (i,) - index_offset_phase(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier whereby to identify phases implicitly. + dim: (n_c,) indices_phase(NX_INT): unit: NX_UNITLESS doc: | Identifier whereby to identify phase for each crystal explicitly. dimensions: - dim: (i,) + dim: (n_c,) # EXAMPLES FOR DESCRIPTOR VALUES, SUMMARY STATISTICS - boundary_contact(NX_BOOLEAN): + # NX_BOOLEAN is a better fit for boundary_contact but currently + # not supported by Matlab + boundary_contact(NX_UINT): doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the feature makes contact with the edge of the ROI. + False, if the feature does not make contact with the edge of the ROI. dimensions: - dim: (i,) + dim: (n_c,) orientation_spread(NX_NUMBER): unit: NX_ANGLE doc: | @@ -240,25 +284,28 @@ NXmicrostructure(NXobject): of that crystal evaluated as a summary statistic for all probed positions vs the average disorientation of that crystal. dimensions: - dim: (i,) + dim: (n_c,) length(NX_NUMBER): unit: NX_LENGTH doc: | Length of each crystal dimensions: - dim: (i,) + dim: (n_c,) area(NX_NUMBER): unit: NX_AREA doc: | Area of each crystal. dimensions: - dim: (i,) + dim: (n_c,) volume(NX_NUMBER): unit: NX_VOLUME doc: | Volume of each crystal dimensions: - dim: (i,) + dim: (n_c,) + orientation(NXrotations): + doc: | + Possibility to store the mean orientation of the grain. interfaces(NXobject): doc: | One- or two-dimensional projections or three-dimensional representation of interfaces @@ -267,13 +314,21 @@ NXmicrostructure(NXobject): An example for a surface defect. Most important are interfaces such as grain and phase boundaries but factually interfaces also exist between the environment and crystals exposed at the surface of the specimen or internal surfaces like between crystals, cracks, or pores. + + Interfaces are typically reported as discretized features. For interface projections on the 2D plane + these are most frequently polyline segments. For interface patches in 3D these are most frequently + triangulations. Descriptions with continuous functions are seldom used unless simplified configurations + are studied in modeling and theoretical studies. + + When using discretizations the individual interface segments need to be distinguished from the interfaces + themselves. Consequently, there are two sets of indices. representation(NX_CHAR): doc: | Reference to an instance of: * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. @@ -281,7 +336,7 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | How many interfaces are distinguished. - index_offset_interface(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | First identifier whereby to identify interfaces implicitly. @@ -292,7 +347,7 @@ NXmicrostructure(NXobject): An array with as many entries as interfaces or their projections. dimensions: - dim: (i,) + dim: (n_i,) # topological view, interface specification through the the pair of crystals sharing an interface indices_crystal(NX_INT): @@ -302,7 +357,7 @@ NXmicrostructure(NXobject): An array with as many pairs as interfaces or their projections. dimensions: - dim: (i, 2) + dim: (n_i, 2) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. @@ -313,7 +368,7 @@ NXmicrostructure(NXobject): An array with as many pairs as interfaces or their projections. dimensions: - dim: (i, 2) + dim: (n_i, 2) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. @@ -323,48 +378,49 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional - projections of these as those typically measured in electron microscopy. - In the case of a two-dimensional projection interfaces are interface traces and hence - they have two terminating junctions while in reality the interface is a surface patch - that is bounded by several triple lines. + projections. The latter situation applies typically for characterization with electron + microscopy. + + In the case of a two-dimensional projection interfaces are interface traces. These have + two terminating junctions. In three dimensions though the interface is a surface patch + that is bounded by multiple triple lines. Number of triple_junctions adjoining each interface. This array resolves the number of values along the second dimension for the field indices_triple_junctions. dimensions: - dim: (n_interfaces,) + dim: (n_i,) indices_triple_junction(NX_INT): unit: NX_UNITLESS doc: | Set of pairs of indices_triple_junction for each interface. - An array with as many tuples along the first dimension i - as interfaces or their projections. - An array with as many values + An array with as many tuples of pairs to describe + all junctions about all interfaces. dimensions: - dim: (i, j) + dim: (i,) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): + boundary_contact(NX_UINT): doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the interface makes contact with the edge of the ROI. + False, if the interface does not make contact with the edge of the ROI. dimensions: - dim: (i,) + dim: (n_i,) surface_energy(NX_NUMBER): unit: NX_ANY doc: | Gibbs free surface energy for each interface. dimensions: - dim: (i,) + dim: (n_i,) mobility(NX_NUMBER): unit: NX_ANY doc: | Non-intrinsic mobility of each interface. dimensions: - dim: (i,) + dim: (n_i,) length(NX_NUMBER): unit: NX_LENGTH doc: | @@ -373,13 +429,13 @@ NXmicrostructure(NXobject): This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. dimensions: - dim: (i,) + dim: (n_i,) area(NX_NUMBER): unit: NX_AREA doc: | The surface area of all interfaces. dimensions: - dim: (i,) + dim: (n_i,) triple_junctions(NXobject): doc: | Projections or representations of junctions at which three interfaces meet. @@ -403,7 +459,7 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS doc: | Number of triple junctions. - index_offset_triple_junction(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | First identifier to identify triple junctions implicitly. @@ -412,7 +468,7 @@ NXmicrostructure(NXobject): doc: | Identifier to identify each triple junction explicitly. dimensions: - dim: (i,) + dim: (n_tj,) # various strategies are used to talk about aspects of triple junctions, some examples follow # example i) triple points as projections of triple lines have locations @@ -422,23 +478,23 @@ NXmicrostructure(NXobject): Set of identifier for positions whereby to identify the location of each junction. dimensions: - dim: (i,) + dim: (n_tj,) \@use_these(NX_CHAR): doc: | The specific identifiers whereby to resolve ambiguities. - position(NX_INT): + position(NX_NUMBER): unit: NX_LENGTH doc: | Explicit positions. dimensions: - dim: (i, d) + dim: (n_tj, d) indices_crystal(NX_INT): unit: NX_UNITLESS doc: | Set of tuples of identifier of crystals connected to the junction for each triple junction. dimensions: - dim: (i, 3) + dim: (n_tj, 3) # example ii) three interfaces (maybe projections of them) meet at a triple junction indices_interface(NX_INT): @@ -447,7 +503,7 @@ NXmicrostructure(NXobject): Set of tuples of identifier of interfaces connected to the junction for each triple junction. dimensions: - dim: (i, 3) + dim: (n_tj, 3) \@use_these(NX_CHAR): doc: | The specific interface identifiers whereby to resolve ambiguities. @@ -459,31 +515,31 @@ NXmicrostructure(NXobject): Set of tuples of identifier for polyline segments connected to the junction for each triple junction. dimensions: - dim: (i, 3) + dim: (n_tj, 3) \@use_these(NX_CHAR): doc: | The specific indices_polyline whereby to resolve ambiguities. # example iv) e.g. crystals of three different phases meet at a triple junction # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): + boundary_contact(NX_UINT): doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the triple line makes contact with the edge of the ROI. + False, if the triple line does not make contact with the edge of the ROI. dimensions: - dim: (i,) + dim: (n_tj,) line_energy(NX_NUMBER): unit: NX_ANY doc: | Specific line energy of each triple junction dimensions: - dim: (i,) + dim: (n_tj,) mobility(NX_NUMBER): unit: NX_ANY doc: | Non-intrinsic mobility of each triple junction. dimensions: - dim: (i,) + dim: (n_tj,) length(NX_NUMBER): unit: NX_LENGTH doc: | @@ -492,29 +548,37 @@ NXmicrostructure(NXobject): This is not necessarily the same as the length of the individual polyline segments whereby the junction is discretized. dimensions: - dim: (i,) + dim: (n_tj,) volume(NX_NUMBER): unit: NX_VOLUME doc: | - The volume of the each triple junction + The volume about each triple junction. + + Respective cut-off criteria need to be specified. dimensions: - dim: (i,) + dim: (n_tj,) quadruple_junctions(NXobject): doc: | Quadruple junctions as a region where four crystals meet. - An example for a point defect. + An example for a point (like) defect. + + Thermodynamically such junctions can be unstable. + Specifically when discretizations are used in simulations + that do not address the thermodynamics of and splitting characteristics + of junctions in cases when more than four crystals meet, it is possible + that so-called higher-order junctions are observed. representation(NX_CHAR): doc: | Reference to an instance of: * :ref:`NXcg_point` - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks number_of_junctions(NX_UINT): unit: NX_UNITLESS doc: | Number of quadruple junctions. - index_offset_quadruple_junction(NX_INT): + index_offset(NX_INT): unit: NX_UNITLESS doc: | First identifier to identify quadruple junctions implicitly. @@ -533,16 +597,16 @@ NXmicrostructure(NXobject): Set of identifier for positions whereby to identify the location of each junction. dimensions: - dim: (i,) + dim: (n_qj,) \@use_these(NX_CHAR): doc: | The specific point identifier whereby to resolve ambiguities. - position(NX_INT): + position(NX_NUMBER): unit: NX_LENGTH doc: | Explicit positions. dimensions: - dim: (i, 3) + dim: (n_qj, d) # example ii) four crystals meet at a quadruple junction indices_crystal(NX_INT): @@ -551,7 +615,7 @@ NXmicrostructure(NXobject): Set of tuples of identifier of crystals connected to the junction for each junction. dimensions: - dim: (i, 4) + dim: (n_qj, 4) \@use_these(NX_CHAR): doc: | The specific identifier to instances of crystal identifiers whereby to resolve @@ -562,7 +626,7 @@ NXmicrostructure(NXobject): Set of tuples of identifier of interfaces connected to the junction for each junction. dimensions: - dim: (i, 4) + dim: (n_qj, 4) \@use_these(NX_CHAR): doc: | The specific identifier to instances of interface identifiers whereby to resolve @@ -575,7 +639,7 @@ NXmicrostructure(NXobject): Set of tuples of identifier for triple junctions connected to the junction for each quadruple junction. dimensions: - dim: (i, 3) + dim: (n_qj, 3) \@use_these(NX_CHAR): doc: | The specific identifier to instances of triple junction identifiers whereby to @@ -588,34 +652,34 @@ NXmicrostructure(NXobject): Set of tuples of identifier for phases of crystals connected to the junction for each quadruple junction. dimensions: - dim: (i, 4) + dim: (n_qj, 4) \@use_these(NX_CHAR): doc: | The specific identifier to instances of phase identifier whereby to resolve ambiguities. # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): + boundary_contact(NX_UINT): doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the junction makes contact with the edge of the ROI. + True, if the junction does not make contact with the edge of the ROI. dimensions: - dim: (i,) + dim: (n_qj,) energy(NX_NUMBER): unit: NX_ANY doc: | Energy of the quadruple_junction as a defect. dimensions: - dim: (i,) + dim: (n_qj,) mobility(NX_NUMBER): unit: NX_ANY doc: | Non-intrinsic mobility of each quadruple_junction. dimensions: - dim: (i,) + dim: (n_qj,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d70ed9610c7e4918d068e2d4a7a4375e1698e3a3ced0a087fc29bbafc244b580 +# eb5e00eb3237bd7b515f0fc62d9aa11317fe87703a4a4cca2d8cc939919d6948 # # # # # @@ -719,58 +803,83 @@ NXmicrostructure(NXobject): # Whether one uses a continuum or atomic scale description of materials, these are always a model only of # the true internal structure of a material. Such models are useful as they enable a coarse-graining and # categorizing of properties and representational aspects from which measured or simulated descriptions -# can be correlated with properties, i.e. descriptor values. +# can be correlated with properties, i.e. descriptor values. The base class here can be used to describe +# the structural aspect of a region-of-interest for a specimen that was investigated or a computer +# simulation that was performed for a virtual specimen. # -# Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. -# Therefore, the characterized microstructure may not have probed the same structure as of the untreated +# Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, +# the characterized microstructure may not turn out to be the same structure as of the untreated # sample from which the region-of-interests on the specimen were sampled. # # Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' # structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually -# always sample this evolution. Most microscopy techniques support to generate only a two-dimensional -# representation (projection) of the characterized material. Often materials are characterized only for -# specific states or via sampling coarsely in time relative to the timescale at which the -# physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. +# always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation +# (projection) of the characterized material volume. Often materials are characterized only for specific states +# or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. +# This is typically a compromise between the research questions and technical surplus practical limitations. # -# The term microstructural feature covers here crystals and all sorts of crystal defects within the material. -# A key challenge with the description of representations and properties of microstructural features is that -# features with different dimensionality exist and combinations of features of different dimensionality are -# frequently expected to be documented with intuitive naming conventions using flat property lists. -# For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation -# of such dictionaries in the literature and the metadata section of public data repositories. +# The term microstructural feature covers here crystals and all sorts of crystal defects within the material +# (interfaces, triple junctions, dislocations, pores, etc.). +# A key challenge with the description of representations and properties of such microstructural features is that +# they can be represented and view as features with different dimensionality. Furthermore, combinations of features of +# different dimensionality are frequently expected to be documented with intuitive naming conventions when +# flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based +# on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. # # NXmicrostructure is an attempt to standardize these descriptions stronger. # -# The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in -# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. -# Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, -# which gives typically rise to a plethora of configurations of which some yield useful properties. +# For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and +# junctions of different types of crystal defects. The term grain describes a contiguous region of material that is +# delineated by interphases (phase or grain boundaries). With its origin motivated by light optical microscopy though +# a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. +# In this base class we use the term and respective group crystals though for single crystals and grains. +# The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume +# that the internal structure of these grains can be described with homogenized effective properties. +# If alternatively the individual structural crystalline or features of this grain should be distinguished +# it is useful to instantiate these as individual instances of crystals. +# +# Grain boundaries and phase boundaries are two main categories of interfaces. +# A grain boundary delineates two regions with similar crystal structure and phase but different orientation. +# A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically +# but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two +# phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments +# but considers that atomic segregation is an equally important structural aspect to consider when classifying grain +# boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties +# is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and +# `A. Sutton and R. W. Baluffi Interfaces in Crystalline Materials`_. +# +# Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in +# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. +# Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, +# or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material +# properties or affect material properties. # # Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values # which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms # are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional -# description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, -# shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of -# in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three -# adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that -# along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. +# description such as a triple line or a triple point as the projection of a line. Therefore, different representations can +# be used to describe the location, shape, and structure of such defect. +# +# This base class provides definitions for crystals, grains, interphases, triple junctions, and quadruple junctions thus covering, +# volumetric, patch, line, and point like features that can serve as examples for future extension. # -# It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the -# typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, -# these are crystals, interfaces, triple lines, quadruple junctions. +# As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable +# objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations +# as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- +# triple-line junctions, likewise dislocations form own junctions. # -# The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ -# and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. +# The description took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ +# and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. # # Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined # on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers -# for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. +# for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. # # # # -# Discouraged free-text field for leaving comments. +# Discouraged free-text field for leaving comments # # # @@ -839,6 +948,9 @@ NXmicrostructure(NXobject): # # # +# # # # @@ -846,17 +958,33 @@ NXmicrostructure(NXobject): # (NXcsg): # (NXcontinuous_function): # examples for specific frequently discussed microstructural features--> -# +# # # The chemical composition of this microstructure (region). # # -# +# # # # # # +# +# +# Different (thermodynamic) phases can be distinguished for the region-of- +# interest. +# +# +# +# First identifier whereby to identify phases implicitly. +# +# +# +# +# Instances should use phase as a prefix. +# +# +# # # # One- or two-dimensional projections, or three-dimensional representations of crystals. @@ -878,8 +1006,8 @@ NXmicrostructure(NXobject): # # * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) # * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions -# (like in computer simulations or 3D experiments) +# * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) +# (like in computer simulations or 3D experiments) # # which represent the geometrical entities of the discretization. # @@ -898,7 +1026,7 @@ NXmicrostructure(NXobject): # Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. # # -# +# # # First identifier whereby to identify crystals implicitly. # @@ -908,30 +1036,27 @@ NXmicrostructure(NXobject): # Identifier whereby to identify each crystal explicitly. # # -# +# # # -# -# -# First identifier whereby to identify phases implicitly. -# -# # # # Identifier whereby to identify phase for each crystal explicitly. # # -# +# # # -# -# +# +# # -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. +# True, if the feature makes contact with the edge of the ROI. +# False, if the feature does not make contact with the edge of the ROI. # # -# +# # # # @@ -941,7 +1066,7 @@ NXmicrostructure(NXobject): # average disorientation of that crystal. # # -# +# # # # @@ -949,7 +1074,7 @@ NXmicrostructure(NXobject): # Length of each crystal # # -# +# # # # @@ -957,7 +1082,7 @@ NXmicrostructure(NXobject): # Area of each crystal. # # -# +# # # # @@ -965,9 +1090,14 @@ NXmicrostructure(NXobject): # Volume of each crystal # # -# +# # # +# +# +# Possibility to store the mean orientation of the grain. +# +# # # # @@ -977,6 +1107,14 @@ NXmicrostructure(NXobject): # An example for a surface defect. Most important are interfaces such as grain and phase boundaries # but factually interfaces also exist between the environment and crystals exposed at the # surface of the specimen or internal surfaces like between crystals, cracks, or pores. +# +# Interfaces are typically reported as discretized features. For interface projections on the 2D plane +# these are most frequently polyline segments. For interface patches in 3D these are most frequently +# triangulations. Descriptions with continuous functions are seldom used unless simplified configurations +# are studied in modeling and theoretical studies. +# +# When using discretizations the individual interface segments need to be distinguished from the interfaces +# themselves. Consequently, there are two sets of indices. # # # @@ -984,7 +1122,7 @@ NXmicrostructure(NXobject): # # * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) # * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks # (like in computer simulations or 3D experiments) # # which represent the geometrical entities of the discretization. @@ -995,7 +1133,7 @@ NXmicrostructure(NXobject): # How many interfaces are distinguished. # # -# +# # # First identifier whereby to identify interfaces implicitly. # @@ -1007,7 +1145,7 @@ NXmicrostructure(NXobject): # An array with as many entries as interfaces or their projections. # # -# +# # # # @@ -1018,7 +1156,7 @@ NXmicrostructure(NXobject): # An array with as many pairs as interfaces or their projections. # # -# +# # # # @@ -1034,7 +1172,7 @@ NXmicrostructure(NXobject): # An array with as many pairs as interfaces or their projections. # # -# +# # # # @@ -1047,29 +1185,29 @@ NXmicrostructure(NXobject): # # # Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional -# projections of these as those typically measured in electron microscopy. -# In the case of a two-dimensional projection interfaces are interface traces and hence -# they have two terminating junctions while in reality the interface is a surface patch -# that is bounded by several triple lines. +# projections. The latter situation applies typically for characterization with electron +# microscopy. +# +# In the case of a two-dimensional projection interfaces are interface traces. These have +# two terminating junctions. In three dimensions though the interface is a surface patch +# that is bounded by multiple triple lines. # # Number of triple_junctions adjoining each interface. This array resolves the number of # values along the second dimension for the field indices_triple_junctions. # # -# -# +# +# # # # # Set of pairs of indices_triple_junction for each interface. # -# An array with as many tuples along the first dimension i -# as interfaces or their projections. -# An array with as many values +# An array with as many tuples of pairs to describe +# all junctions about all interfaces. # # # -# # # # @@ -1078,13 +1216,13 @@ NXmicrostructure(NXobject): # # # -# +# # -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. +# True, if the interface makes contact with the edge of the ROI. +# False, if the interface does not make contact with the edge of the ROI. # # -# +# # # # @@ -1092,7 +1230,7 @@ NXmicrostructure(NXobject): # Gibbs free surface energy for each interface. # # -# +# # # # @@ -1100,7 +1238,7 @@ NXmicrostructure(NXobject): # Non-intrinsic mobility of each interface. # # -# +# # # # @@ -1111,7 +1249,7 @@ NXmicrostructure(NXobject): # polyline segments whereby the interface is discretized. # # -# +# # # # @@ -1119,7 +1257,7 @@ NXmicrostructure(NXobject): # The surface area of all interfaces. # # -# +# # # # @@ -1150,7 +1288,7 @@ NXmicrostructure(NXobject): # Number of triple junctions. # # -# +# # # First identifier to identify triple junctions implicitly. # @@ -1160,7 +1298,7 @@ NXmicrostructure(NXobject): # Identifier to identify each triple junction explicitly. # # -# +# # # # -# +# # -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. +# True, if the triple line makes contact with the edge of the ROI. +# False, if the triple line does not make contact with the edge of the ROI. # # -# +# # # # @@ -1246,7 +1384,7 @@ NXmicrostructure(NXobject): # Specific line energy of each triple junction # # -# +# # # # @@ -1254,7 +1392,7 @@ NXmicrostructure(NXobject): # Non-intrinsic mobility of each triple junction. # # -# +# # # # @@ -1265,15 +1403,17 @@ NXmicrostructure(NXobject): # polyline segments whereby the junction is discretized. # # -# +# # # # # -# The volume of the each triple junction +# The volume about each triple junction. +# +# Respective cut-off criteria need to be specified. # # -# +# # # # @@ -1281,14 +1421,20 @@ NXmicrostructure(NXobject): # # Quadruple junctions as a region where four crystals meet. # -# An example for a point defect. +# An example for a point (like) defect. +# +# Thermodynamically such junctions can be unstable. +# Specifically when discretizations are used in simulations +# that do not address the thermodynamics of and splitting characteristics +# of junctions in cases when more than four crystals meet, it is possible +# that so-called higher-order junctions are observed. # # # # Reference to an instance of: # # * :ref:`NXcg_point` -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks # # # @@ -1296,7 +1442,7 @@ NXmicrostructure(NXobject): # Number of quadruple junctions. # # -# +# # # First identifier to identify quadruple junctions implicitly. # @@ -1317,7 +1463,7 @@ NXmicrostructure(NXobject): # junction. # # -# +# # # # @@ -1325,13 +1471,13 @@ NXmicrostructure(NXobject): # # # -# +# # # Explicit positions. # # -# -# +# +# # # # @@ -1341,7 +1487,7 @@ NXmicrostructure(NXobject): # junction. # # -# +# # # # @@ -1357,7 +1503,7 @@ NXmicrostructure(NXobject): # junction. # # -# +# # # # @@ -1374,7 +1520,7 @@ NXmicrostructure(NXobject): # each quadruple junction. # # -# +# # # # @@ -1391,7 +1537,7 @@ NXmicrostructure(NXobject): # each quadruple junction. # # -# +# # # # @@ -1402,13 +1548,13 @@ NXmicrostructure(NXobject): # # # -# +# # -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. +# True, if the junction makes contact with the edge of the ROI. +# True, if the junction does not make contact with the edge of the ROI. # # -# +# # # # @@ -1416,7 +1562,7 @@ NXmicrostructure(NXobject): # Energy of the quadruple_junction as a defect. # # -# +# # # # @@ -1424,7 +1570,7 @@ NXmicrostructure(NXobject): # Non-intrinsic mobility of each quadruple_junction. # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index a11a1d11ea..cef6e11cd3 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -83,7 +83,7 @@ NXmicrostructure_odf(NXprocess): dim: (k,) sampling(NXobject): doc: | - The ODF intensity values (weights) as sampled with a software + The ODF intensity values (weights) as sampled with a software. resolution(NX_NUMBER): unit: NX_ANGLE doc: | @@ -110,7 +110,7 @@ NXmicrostructure_odf(NXprocess): This is one example of typical default plots used in the texture community in materials engineering. - Mind that when parameterized using Euler angles the orientation space is a distorted space. + Mind that the orientation space is a distorted space when it using an Euler angle parameterization. Therefore, equivalent orientations show intensity contributions in eventually multiple locations. # \@signal: intensity @@ -155,7 +155,7 @@ NXmicrostructure_odf(NXprocess): # \@long_name(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cb4a53053dcf07ad3f1c4a9eb44256a9c03afa2696cc0ab50ee634cc1ddbf088 +# dbafdd60be3fa8ae011100f19bf78577fd2bb2379dc3aa898cbdbef5eebbc048 # # # For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and junctions of different types of crystal defects. The term grain describes a contiguous region of material that is - delineated by interphases (phase or grain boundaries). With its origin motivated by light optical microscopy though + delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. In this base class we use the term and respective group crystals though for single crystals and grains. The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume @@ -163,8 +163,8 @@ The number of line defects.--> phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments but considers that atomic segregation is an equally important structural aspect to consider when classifying grain boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties - is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and - `A. Sutton and R. W. Baluffi Interfaces in Crystalline Materials`_. + is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and A. Sutton and R. W. Baluffi, + Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. @@ -178,7 +178,7 @@ The number of line defects.--> description such as a triple line or a triple point as the projection of a line. Therefore, different representations can be used to describe the location, shape, and structure of such defect. - This base class provides definitions for crystals, grains, interphases, triple junctions, and quadruple junctions thus covering, + This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, volumetric, patch, line, and point like features that can serve as examples for future extension. As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable @@ -266,9 +266,9 @@ the idea is we may wish to run as many grain reconstructions as we want and add - + @@ -325,7 +325,6 @@ examples for specific frequently discussed microstructural features--> * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) - (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. @@ -753,6 +752,8 @@ EXAMPLES FOR DESCRIPTOR VALUES--> * :ref:`NXcg_point` * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks + + which represent the geometrical entities of the discretization. diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index c33081b10a..0bb68c9432 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -32,7 +32,7 @@ doc: | For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and junctions of different types of crystal defects. The term grain describes a contiguous region of material that is - delineated by interphases (phase or grain boundaries). With its origin motivated by light optical microscopy though + delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. In this base class we use the term and respective group crystals though for single crystals and grains. The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume @@ -47,8 +47,8 @@ doc: | phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments but considers that atomic segregation is an equally important structural aspect to consider when classifying grain boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties - is provided in e.g. `W. Bollmann `_ and - `A. Sutton and R. W. Baluffi Interfaces in Crystalline Materials`_. + is provided in e.g. `W. Bollmann `_ and A. Sutton and R. W. Baluffi, + Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. @@ -62,7 +62,7 @@ doc: | description such as a triple line or a triple point as the projection of a line. Therefore, different representations can be used to describe the location, shape, and structure of such defect. - This base class provides definitions for crystals, grains, interphases, triple junctions, and quadruple junctions thus covering, + This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, volumetric, patch, line, and point like features that can serve as examples for future extension. As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable @@ -236,7 +236,6 @@ NXmicrostructure(NXobject): * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) - (like in computer simulations or 3D experiments) which represent the geometrical entities of the discretization. number_of_crystals(NX_UINT): @@ -574,6 +573,8 @@ NXmicrostructure(NXobject): * :ref:`NXcg_point` * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks + + which represent the geometrical entities of the discretization. number_of_junctions(NX_UINT): unit: NX_UNITLESS doc: | @@ -679,7 +680,7 @@ NXmicrostructure(NXobject): dim: (n_qj,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eb5e00eb3237bd7b515f0fc62d9aa11317fe87703a4a4cca2d8cc939919d6948 +# 9cc695e350320f25291b2bc291347defc2e4d947dd53e01580f21cb7e8f40793 # # # +# # # # @@ -1007,7 +1008,6 @@ NXmicrostructure(NXobject): # * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) # * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) # * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) -# (like in computer simulations or 3D experiments) # # which represent the geometrical entities of the discretization. # @@ -1435,6 +1435,8 @@ NXmicrostructure(NXobject): # # * :ref:`NXcg_point` # * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks +# +# which represent the geometrical entities of the discretization. # # # From e6a3d9ddcffd260065bb368d70cd67a3bea83946 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 7 Apr 2025 09:34:43 +0200 Subject: [PATCH 09/57] Adding color_model to ipf, tsl default if mtex is not present, if mtex is present writing tsl and mtex --- contributed_definitions/NXem.nxdl.xml | 1 + .../NXmicrostructure_ipf.nxdl.xml | 183 ++++++++--------- contributed_definitions/nyaml/NXem.yaml | 4 +- .../nyaml/NXmicrostructure_ipf.yaml | 189 +++++++++--------- 4 files changed, 197 insertions(+), 180 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 3990428105..8bef58ebfb 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1701,6 +1701,7 @@ not wish to duplicate all payload data--> + diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml index 20b3ad99f0..455adde46b 100644 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -25,42 +25,51 @@ - Number of pixel along the z slowest direction. + Number of pixel along the z slowest direction. - Number of pixel along the y slow direction. + Number of pixel along the y slow direction. - Number of pixel along the x fast direction. + Number of pixel along the x fast direction. - Number of RGB values along the fastest direction, always three. + Number of RGB values along the fastest direction, always three. - Base class to store an inverse pole figure (IPF) mapping (IPF map). + Base class to store an inverse pole figure (IPF) mapping (IPF map). - Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - - If the field depends_on is not provided but parents of the instance of this base class or its - specializations define an instance of :ref:`NXcoordinate_system`, projection_direction - is defined in this coordinate system. - - If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. + + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. + + If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + + + The algorithm whereby orientations are colored. + + + + + + - The direction along which orientations are projected. + The direction along which orientations are projected. @@ -68,25 +77,25 @@ - Details about the original grid. - - Here original grid means the grid for which the IPF map was computed when that - IPF map was exported from the tech partner's file format representation. + Details about the original grid. + + Here original grid means the grid for which the IPF map was computed when that + IPF map was exported from the tech partner's file format representation. - Details about the grid onto which the IPF is recomputed. - - Rescaling the visualization of the IPF map may be needed to enable - visualization in specific software tools like H5Web. + Details about the grid onto which the IPF is recomputed. + + Rescaling the visualization of the IPF map may be needed to enable + visualization in specific software tools like H5Web. - How where orientation values at positions of input_grid computed to values on output_grid. - - Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. + How where orientation values at positions of input_grid computed to values on output_grid. + + Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. @@ -94,49 +103,47 @@ - Inverse pole figure mapping. - - Instances named phase0 should by definition refer to the null phase notIndexed. - Inspect the definition of :ref:`NXphase` and its field identifier_phase - for further details. - - Details about possible regridding and associated interpolation - during the computation of the IPF map visualization can be stored - using the input_grid, output_grid, and interpolation fields. - - The main purpose of this map is to offer a normalized default representation - of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues - and users of IPF maps together to discuss which pieces of information need storage. - - We are convinced a step-by-step design and community-driven discussion is a practical - strategy to work towards an interoperable description and data model for exchanging - IPF maps as a specific community-accepted method to convey orientation maps. - - 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 one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques an - understanding if the dataset is worth to become reused or repurposed. + Inverse pole figure mapping. + + Instances named phase0 should by definition refer to the null phase notIndexed. + Inspect the definition of :ref:`NXphase` and its field identifier_phase + for further details. + + Details about possible regridding and associated interpolation + during the computation of the IPF map visualization can be stored + using the input_grid, output_grid, and interpolation fields. + + The main purpose of this map is to offer a normalized default representation + of the IPF map for consumption by a research data management system (RDMS). + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues + and users of IPF maps together to discuss which pieces of information need storage. + + We are convinced a step-by-step design and community-driven discussion is a practical + strategy to work towards an interoperable description and data model for exchanging + IPF maps as a specific community-accepted method to convey orientation maps. + + 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 one common understanding which enables also those users who are + not necessarily experts in all the details of the underlying techniques an + understanding if the dataset is worth to become reused or repurposed. - +answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located +tech partners oftentimes do not report to more than calibrated pixel position--> - Inverse pole figure color code for each map coordinate. + Inverse pole figure color code for each map coordinate. @@ -146,7 +153,7 @@ tech partners oftentimes do not report to more than calibrated pixel position - Pixel center coordinate calibrated for step size along the z axis of the map. + Pixel center coordinate calibrated for step size along the z axis of the map. @@ -155,7 +162,7 @@ tech partners oftentimes do not report to more than calibrated pixel position - Pixel center coordinate calibrated for step size along the y axis of the map. + Pixel center coordinate calibrated for step size along the y axis of the map. @@ -164,7 +171,7 @@ tech partners oftentimes do not report to more than calibrated pixel position - Pixel center coordinate calibrated for step size along the x axis of the map. + Pixel center coordinate calibrated for step size along the x axis of the map. @@ -175,41 +182,39 @@ tech partners oftentimes do not report to more than calibrated pixel position title:--> - The color code which maps colors to orientation in the fundamental zone. - - 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 a color to each - point in the fundamental zone. - - Different mapping models are used. These implement (slightly) different - scaling relations. Differences exist across representations of tech partners. - - 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) - * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it can not yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. + The color code which maps colors to orientation in the fundamental zone. + + 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 a color to each + point in the fundamental zone. + + Different mapping models are used. These implement (slightly) different + scaling relations. Differences exist across representations of tech partners. + + 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) + * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it can not yet be + visualized using tools like H5Web, which is why for now the matrix + of a rasterized image which is rendered by the backend tool gets + copied into an RGB matrix to offer a default plot. - + - Inverse pole figure color code for each map coordinate. + Inverse pole figure color code for each map coordinate. @@ -219,7 +224,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! - Pixel along the y-axis. + Pixel along the y-axis. @@ -228,7 +233,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! - Pixel along the x-axis. + Pixel along the x-axis. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index d6ddeba2bc..c1c1497ba3 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1503,6 +1503,7 @@ NXem(NXobject): IPF(NXmicrostructure_ipf): nameType: any exists: recommended + color_model(NX_CHAR): projection_direction(NX_NUMBER): map(NXdata): \@signal(NX_CHAR): @@ -1604,7 +1605,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 513dcbb7a7d724384203726112fcf8c7b4b6036b4d3705c577c31b116d51351f +# 0a9138bae87afefffa5a84c62a07d8659a230c440064396310411a2fc79e1f14 # # # # +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index eefdc0d493..50a16013fc 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -21,6 +21,10 @@ NXmicrostructure_ipf(NXprocess): is defined in this coordinate system. If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + color_model(NX_CHAR): + doc: | + The algorithm whereby orientations are colored. + enumeration: [is_open, values] projection_direction(NX_NUMBER): unit: NX_UNITLESS doc: | @@ -186,7 +190,7 @@ NXmicrostructure_ipf(NXprocess): # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 68b5b9282aa6a9fa4f4ba2a926a136b94e337da62952a08d186b7a0bae9c7fc2 +# 58c563eb017c564647c865ff741671f98c3ce2663396d770586802f51abfa741 # # # # -# +# answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located +# tech partners oftentimes do not report to more than calibrated pixel position--> # -# Inverse pole figure color code for each map coordinate. +# Inverse pole figure color code for each map coordinate. # # # @@ -335,7 +346,7 @@ NXmicrostructure_ipf(NXprocess): # # # -# Pixel center coordinate calibrated for step size along the z axis of the map. +# Pixel center coordinate calibrated for step size along the z axis of the map. # # # @@ -344,7 +355,7 @@ NXmicrostructure_ipf(NXprocess): # # # -# Pixel center coordinate calibrated for step size along the y axis of the map. +# Pixel center coordinate calibrated for step size along the y axis of the map. # # # @@ -353,7 +364,7 @@ NXmicrostructure_ipf(NXprocess): # # # -# Pixel center coordinate calibrated for step size along the x axis of the map. +# Pixel center coordinate calibrated for step size along the x axis of the map. # # # @@ -364,41 +375,39 @@ NXmicrostructure_ipf(NXprocess): # title:--> # # -# The color code which maps colors to orientation in the fundamental zone. -# -# 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 a color to each -# point in the fundamental zone. -# -# Different mapping models are used. These implement (slightly) different -# scaling relations. Differences exist across representations of tech partners. -# -# 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) -# * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). -# -# Details are implementation-specific and not standardized yet. -# -# Given that the SST has a complicated geometry, it can not yet be -# visualized using tools like H5Web, which is why for now the matrix -# of a rasterized image which is rendered by the backend tool gets -# copied into an RGB matrix to offer a default plot. +# The color code which maps colors to orientation in the fundamental zone. +# +# 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 a color to each +# point in the fundamental zone. +# +# Different mapping models are used. These implement (slightly) different +# scaling relations. Differences exist across representations of tech partners. +# +# 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) +# * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). +# +# Details are implementation-specific and not standardized yet. +# +# Given that the SST has a complicated geometry, it can not yet be +# visualized using tools like H5Web, which is why for now the matrix +# of a rasterized image which is rendered by the backend tool gets +# copied into an RGB matrix to offer a default plot. # # # -# +# # -# Inverse pole figure color code for each map coordinate. +# Inverse pole figure color code for each map coordinate. # # # @@ -408,7 +417,7 @@ NXmicrostructure_ipf(NXprocess): # # # -# Pixel along the y-axis. +# Pixel along the y-axis. # # # @@ -417,7 +426,7 @@ NXmicrostructure_ipf(NXprocess): # # # -# Pixel along the x-axis. +# Pixel along the x-axis. # # # From 71a358eeebc8dcd93d4ddf9d38b904f059102baa Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 7 May 2025 14:11:31 +0200 Subject: [PATCH 10/57] Reverting the use of NXobject in favor for new small base classes as per decision of the NIAC https://github.com/nexusformat/definitions/pull/1423#issuecomment-2842561671 --- contributed_definitions/NXem.nxdl.xml | 74 +- .../NXem_calorimetry.nxdl.xml | 6 +- .../NXem_measurement.nxdl.xml | 28 + .../NXem_simulation.nxdl.xml | 33 + contributed_definitions/NXevent_em.nxdl.xml | 32 + .../NXinteraction_volume_em.nxdl.xml | 55 + .../NXmicrostructure.nxdl.xml | 12 +- .../NXmicrostructure_feature.nxdl.xml | 28 + .../NXmicrostructure_gragles_config.nxdl.xml | 24 +- .../NXmicrostructure_gragles_results.nxdl.xml | 39 +- .../NXmicrostructure_imm_config.nxdl.xml | 10 +- .../NXmicrostructure_imm_results.nxdl.xml | 6 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 6 +- .../NXmicrostructure_mtex_config.nxdl.xml | 12 +- .../NXmicrostructure_odf.nxdl.xml | 8 +- .../NXmicrostructure_pf.nxdl.xml | 4 +- .../NXmicrostructure_score_config.nxdl.xml | 42 +- .../NXmicrostructure_score_results.nxdl.xml | 46 +- contributed_definitions/NXroi.nxdl.xml | 34 + contributed_definitions/nyaml/NXem.yaml | 1895 +---------------- .../nyaml/NXem_calorimetry.yaml | 304 +-- .../nyaml/NXem_measurement.yaml | 5 + .../nyaml/NXem_simulation.yaml | 9 + contributed_definitions/nyaml/NXevent_em.yaml | 9 + .../nyaml/NXinteraction_volume_em.yaml | 33 + .../nyaml/NXmicrostructure.yaml | 909 +------- .../nyaml/NXmicrostructure_feature.yaml | 5 + .../NXmicrostructure_gragles_config.yaml | 394 +--- .../NXmicrostructure_gragles_results.yaml | 344 +-- .../nyaml/NXmicrostructure_imm_config.yaml | 253 +-- .../nyaml/NXmicrostructure_imm_results.yaml | 199 +- .../NXmicrostructure_kanapy_results.yaml | 203 +- .../nyaml/NXmicrostructure_mtex_config.yaml | 4 +- .../nyaml/NXmicrostructure_odf.yaml | 233 +- .../nyaml/NXmicrostructure_pf.yaml | 119 +- .../nyaml/NXmicrostructure_score_config.yaml | 777 +------ .../nyaml/NXmicrostructure_score_results.yaml | 576 +---- contributed_definitions/nyaml/NXroi.yaml | 11 + 38 files changed, 486 insertions(+), 6295 deletions(-) create mode 100644 contributed_definitions/NXem_measurement.nxdl.xml create mode 100644 contributed_definitions/NXem_simulation.nxdl.xml create mode 100644 contributed_definitions/NXevent_em.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_volume_em.nxdl.xml create mode 100644 contributed_definitions/NXmicrostructure_feature.nxdl.xml create mode 100644 contributed_definitions/NXroi.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem_measurement.yaml create mode 100644 contributed_definitions/nyaml/NXem_simulation.yaml create mode 100644 contributed_definitions/nyaml/NXevent_em.yaml create mode 100644 contributed_definitions/nyaml/NXinteraction_volume_em.yaml create mode 100644 contributed_definitions/nyaml/NXmicrostructure_feature.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 8bef58ebfb..3fcca09f78 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -3,7 +3,7 @@ - + - This group should be used to store all event-related (meta)data, - which are typically measured datasets like images and spectra. To avoid that static instrument-related metadata need to be stored - repetitively the NXem application definitions splits the storage of the + repetitively, the NXem application definitions splits the storage of the dynamic (meta)data that typically change for each image and spectrum from the static one. - - - Instances should use event as a name prefix. - + @@ -1542,14 +1537,11 @@ basically optional use of NXaberration therein at least some value required--> - - + - Possibility for documenting a set of simulations of electron beam matter interaction. - - Instances should use simulation as a name prefix. + Documentation for a simulation of electron beam-matter interaction. - + The program with which the simulation was performed. @@ -1557,7 +1549,7 @@ basically optional use of NXaberration therein at least some value required--> - + Programs and libraries representing the computational environment @@ -1567,49 +1559,18 @@ basically optional use of NXaberration therein at least some value required--> - + Configuration of the simulation - + Results of the simulation - - - Description of the volume of interaction between of particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle-resolved sets of trajectories. - - Explicit or implicit descriptions of the geometry of this - interaction volume 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 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 flux through - an imaginary control surface (the iso-surface) 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>`_ - * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ - - Instances should use interaction_volume as a name prefix. - + @@ -1618,11 +1579,8 @@ basically optional use of NXaberration therein at least some value required--> - + - A region-of-interest analyzed either during or after the session for which specific - processed data are available. Instances should use roi as a name prefix. - This concept is related to term `Region Of Interest`_ of the EMglossary standard. .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index a106792656..a7af3b743a 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -3,7 +3,7 @@ * What is the technique about. * General context. * Literature references. - @@ -84,7 +83,7 @@ are aligned with what and how to name things--> - + Programs and libraries representing the computational environment @@ -243,7 +242,6 @@ NXcg_ellipsoid--> * result_with_background * result_without_background - diff --git a/contributed_definitions/NXem_measurement.nxdl.xml b/contributed_definitions/NXem_measurement.nxdl.xml new file mode 100644 index 0000000000..f6213518e8 --- /dev/null +++ b/contributed_definitions/NXem_measurement.nxdl.xml @@ -0,0 +1,28 @@ + + + + + + Base class for ################ + + diff --git a/contributed_definitions/NXem_simulation.nxdl.xml b/contributed_definitions/NXem_simulation.nxdl.xml new file mode 100644 index 0000000000..d6a22901a2 --- /dev/null +++ b/contributed_definitions/NXem_simulation.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + Base class for documenting a set of simulations of electron beam-matter + interaction. + + + + + + diff --git a/contributed_definitions/NXevent_em.nxdl.xml b/contributed_definitions/NXevent_em.nxdl.xml new file mode 100644 index 0000000000..aae803dc61 --- /dev/null +++ b/contributed_definitions/NXevent_em.nxdl.xml @@ -0,0 +1,32 @@ + + + + + + Base class for grouping instances of :ref:`NXevent_data_em`. + + This group should be used to bundle all event-related (meta)data + and measured data including images and spectra. + + + diff --git a/contributed_definitions/NXinteraction_volume_em.nxdl.xml b/contributed_definitions/NXinteraction_volume_em.nxdl.xml new file mode 100644 index 0000000000..129c785080 --- /dev/null +++ b/contributed_definitions/NXinteraction_volume_em.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Base class to group data and descriptions of the volume of interaction for particle-matter interaction. + + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle-resolved sets of trajectories. + + Explicit or implicit descriptions of the geometry of this + interaction volume 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 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 flux through + an imaginary control surface (the iso-surface) 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>`_ + * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ + + + + diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 39d6ac469d..63c488e6ff 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -3,7 +3,7 @@ - + Different (thermodynamic) phases can be distinguished for the region-of- interest. @@ -303,7 +303,7 @@ examples for specific frequently discussed microstructural features--> - + One- or two-dimensional projections, or three-dimensional representations of crystals. @@ -416,7 +416,7 @@ not supported by Matlab--> - + One- or two-dimensional projections or three-dimensional representation of interfaces between crystals as topological entities equivalent to dual_junctions. @@ -578,7 +578,7 @@ not supported by Matlab--> - + Projections or representations of junctions at which three interfaces meet. @@ -734,7 +734,7 @@ EXAMPLES FOR DESCRIPTOR VALUES--> - + Quadruple junctions as a region where four crystals meet. diff --git a/contributed_definitions/NXmicrostructure_feature.nxdl.xml b/contributed_definitions/NXmicrostructure_feature.nxdl.xml new file mode 100644 index 0000000000..b6542466b4 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_feature.nxdl.xml @@ -0,0 +1,28 @@ + + + + + + Base class for documenting structuring features of a microstructure. + + diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 0bafa2f716..dc03de567c 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -3,7 +3,7 @@ - + Programs and libraries representing the computational environment @@ -103,7 +103,7 @@ read the next three from input file - + Configuration when snapshots of the system should be taken. @@ -127,7 +127,7 @@ read the next three from input file - + Configuration when the simulation should be stopped in a controlled manner. Whichever criterion is fulfilled first triggers the controlled stop of @@ -145,7 +145,7 @@ read the next three from input file - + Configuration of numerical details of the solver. @@ -181,7 +181,7 @@ only guru i.e. in C++ code configurable options 1 # 0, E_ITERATIVE, 1, E_SQUARES 0.0 --> - + Configuration of the grid coarsement algorithm whereby the representation of the system is continuously rediscretized such that on average grains @@ -217,7 +217,7 @@ only guru i.e. in C++ code configurable options 3 2 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated--> - + Physically-based model of the assumed mobility of the grain boundaries. @@ -262,7 +262,7 @@ only guru i.e. in C++ code configurable options - + Physically-based model of the assumed grain boundary surface energy. @@ -302,7 +302,7 @@ only guru i.e. in C++ code configurable options 0.01 --> - + A continuum-scale curvature of an interface causes the interface to migrate towards the center of the curvature radius. @@ -313,7 +313,7 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + A continuum-scale difference of the stored elastic energy in dislocation configurations across a grain boundary can exert a driving force on the @@ -332,7 +332,7 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + In case of an applied magnetic field, a difference of the magnetic susceptibility can exert a driving force on the grain boundary such that @@ -346,7 +346,7 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + A triple line mediates the atomic arrangement differences between three interface patches. Therefore, the triple line is a defect that may not diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index dd9d30a8a1..7290012d6d 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -3,7 +3,7 @@ - + Summary quantities which are the result of some post-processing of the snapshot data (averaging, integrating, interpolating) happening in for practical reasons though in while @@ -238,7 +231,7 @@ the typical lean summary statistics flattened--> - + @@ -265,7 +258,7 @@ the typical lean summary statistics flattened--> - + diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index ac239d0c35..321ada5b67 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -3,7 +3,7 @@ - + In texture research component analyses set on the idea that properties of grains different based on orientation with certain regions in orientation @@ -162,7 +162,7 @@ remove 0 all the time 0.00 - + Dislocations are modelled as Rayleigh-distributed mean-field density that can differ between but is constant within grains and sub-grains. @@ -204,7 +204,7 @@ remove 0 all the time 0.00 - + Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. Orientations of the sub-grains are sampled by scattering the orientation diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index eb8c01007e..c073f4cc11 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -3,7 +3,7 @@ - + diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index 6442eba21c..e9c570ceed 100644 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -145,9 +145,9 @@ check against v5.12--> +doc: | +TODO with MTex developers +unit: NX_UNITLESS--> @@ -209,7 +209,11 @@ check against v5.12--> TODO with MTex developers - + + + TODO with MTex developers + + diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index 770dac2740..d9e92a2c0b 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -3,7 +3,7 @@ - + Group to store descriptors and summary statistics for extrema of the ODF. @@ -139,7 +139,7 @@ - + The ODF intensity values (weights) as sampled with a software. diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml index 18809d66a2..5d8f7ec350 100644 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -3,7 +3,7 @@ - + Programs and libraries representing the computational environment @@ -178,7 +177,7 @@ SecondOrderThermalExpCoeff--> - + Details about the geometry and properties of the polycrystal that represents the starting configuration (typically a deformed microstructure) for the simulation. @@ -191,7 +190,6 @@ SecondOrderThermalExpCoeff--> * poisson_voronoi, a discretized poisson voronoi * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. - @@ -215,7 +213,7 @@ SecondOrderThermalExpCoeff--> Average spherical diameter when model is poisson_voronoi. - + Settings for instantiating properties of deformed grains when model is cuboidal or poisson. @@ -282,7 +280,7 @@ SecondOrderThermalExpCoeff--> - + Phenomenological model according to which recrystallization nuclei are placed into the domain whose growth is studied with the simulation. @@ -294,7 +292,6 @@ SecondOrderThermalExpCoeff--> * csr, complete spatial randomness * custom, implementation-specific * gb, nuclei placed at grain boundaries - @@ -316,7 +313,6 @@ SecondOrderThermalExpCoeff--> * ensemble, picking randomly one from ensemble/bunge_euler * random, picking randomly on the SO3 * damask, picking based on information provided in deformation/damask - @@ -324,7 +320,7 @@ SecondOrderThermalExpCoeff--> - + Settings for instantiating properties of nuclei for recrystallizing grains. @@ -350,7 +346,7 @@ SecondOrderThermalExpCoeff--> - + Model for the assumed mobility of grain boundaries with different disorientation implemented as parameterized Turnbull's model for thermally-activated @@ -370,7 +366,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> - + Parameter of the Sebald-Gottstein migration model. @@ -417,7 +413,7 @@ unit: NX_ANGLE--> - + Parameter of the Rollett-Holm migration model. @@ -449,7 +445,7 @@ unit: NX_ANGLE--> - + Time-dependent reduction of the stored energy to account for recovery effects. @@ -462,7 +458,7 @@ unit: NX_ANGLE--> - + Reduction of the grain boundary migration speed due to the presence of dispersoids through which the total grain boundary area of the recrystallization front can be reduced @@ -477,7 +473,7 @@ unit: NX_ANGLE--> - + Parameter of the Zener-Smith drag model when model is zener_smith. @@ -527,7 +523,7 @@ like showing a r(t) plot--> - + Given name of a texture component. @@ -620,7 +616,7 @@ like showing a r(t) plot--> - + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -668,7 +664,7 @@ like showing a r(t) plot--> - + Parameter which control the memory management of cells in the recrystallization front. @@ -707,7 +703,7 @@ like showing a r(t) plot--> - + Perform a statistical analyses of the results as it was proposed @@ -728,10 +724,4 @@ like showing a r(t) plot--> - diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 74a283d937..4ec4448d4a 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -3,7 +3,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>`_ - @@ -133,7 +132,7 @@ inspect comments behind NXmicrostructure--> - + Programs and libraries representing the computational environment @@ -144,11 +143,11 @@ inspect comments behind NXmicrostructure--> +rotation_handedness(NX_CHAR): +rotation_convention(NX_CHAR): +euler_angle_convention(NX_CHAR): +axis_angle_convention(NX_CHAR): +sign_convention(NX_CHAR):--> @@ -229,7 +228,6 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele * 3 - mirror * 4 - von Neumann * 5 - Dirichlet - @@ -246,7 +244,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - + Documentation of the spatiotemporal evolution for each CA domain. @@ -368,19 +366,19 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele @@ -432,7 +430,7 @@ the typically storage-costlier snapshot data--> - + @@ -492,7 +490,7 @@ the typically storage-costlier snapshot data--> - + Details about those cells which in this time step represent the discrete recrystallization front. diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml new file mode 100644 index 0000000000..73af0d7a1d --- /dev/null +++ b/contributed_definitions/NXroi.nxdl.xml @@ -0,0 +1,34 @@ + + + + + + Base class to report on a region-of-interest of material analyzed. + + Do not confuse this base class with :ref:`NXregion`. + + + + + + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index c1c1497ba3..aed7ef0583 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -48,6 +48,8 @@ NXem(NXobject): from conda or python virtualenv environments. program(NX_CHAR): \@version(NX_CHAR): + + identifier_experiment(NX_CHAR): exists: optional experiment_alias(NX_CHAR): @@ -281,7 +283,7 @@ NXem(NXobject): exists: optional doc: | Discouraged free-text field to provide further detail. - consistent_rotations(NXobject): + consistent_rotations(NXparameters): exists: recommended doc: | The conventions used when reporting crystal orientations. @@ -406,11 +408,11 @@ NXem(NXobject): Direction of the positively pointing z-axis base vector of the sample_reference_frame. enumeration: [north, east, south, west, in, out] - DETECTOR_REFERENCE_FRAME(NXcoordinate_system): - nameType: any + detector_reference_frameID(NXcoordinate_system): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | - Instances should use detector_reference_frame as a name prefix. + The reference frame that is defined by a specific detector. depends_on(NX_CHAR): exists: optional doc: | @@ -451,9 +453,8 @@ NXem(NXobject): Direction of the positively pointing z-axis base vector of the detector_reference_frame. enumeration: [north, east, south, west, in, out] - measurement(NXobject): + measurement(NXem_measurement): exists: optional - # the choice if a concept filling content in NXfabrication is recommended or optional # was made such that all for all those components which are typically add-ons in a # microscope it is more likely that individuals will have bought different third-party tools @@ -713,28 +714,23 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] doc: | Instances should use actuator as a name prefix. - events(NXobject): + events(NXevent_em): exists: ['min', '0', 'max', '1'] - # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! doc: | - This group should be used to store all event-related (meta)data, - which are typically measured datasets like images and spectra. To avoid that static instrument-related metadata need to be stored - repetitively the NXem application definitions splits the storage of the + repetitively, the NXem application definitions splits the storage of the dynamic (meta)data that typically change for each image and spectrum from the static one. - (NXevent_data_em): + eventID(NXevent_data_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use event as a name prefix. start_time(NX_DATE_TIME): exists: recommended end_time(NX_DATE_TIME): exists: recommended identifier_sample(NX_CHAR): exists: recommended - # above field is another example for lacking support to define conditional existence constraints (NXimage): exists: ['min', '0', 'max', 'unbounded'] @@ -1333,22 +1329,18 @@ NXem(NXobject): unit: NX_POWER optics(NXoptical_system_em): exists: recommended - - # remains to be discussed based on examples - SIMULATION(NXobject): - nameType: any - exists: ['min', '0', 'max', 'unbounded'] + simulation(NXem_simulation): + exists: optional doc: | - Possibility for documenting a set of simulations of electron beam matter interaction. - - Instances should use simulation as a name prefix. - (NXprogram): + Documentation for a simulation of electron beam-matter interaction. + programID(NXprogram): + nameType: partial exists: recommended doc: | The program with which the simulation was performed. program(NX_CHAR): \@version(NX_CHAR): - environment(NXobject): + environment(NXcollection): exists: recommended doc: | Programs and libraries representing the computational environment @@ -1356,11 +1348,11 @@ NXem(NXobject): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - config(NXobject): + config(NXparameters): exists: optional doc: | Configuration of the simulation - results(NXobject): + results(NXprocess): exists: optional doc: | Results of the simulation @@ -1368,39 +1360,9 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] (NXspectrum): exists: ['min', '0', 'max', 'unbounded'] - INTERACTION_VOLUME(NXobject): - nameType: any + interaction_volumeID(NXinteraction_volume_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Description of the volume of interaction between of particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle-resolved sets of trajectories. - - Explicit or implicit descriptions of the geometry of this - interaction volume 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 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 flux through - an imaginary control surface (the iso-surface) 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. `_ - * `J. F. Ziegler et al. `_ - - Instances should use interaction_volume as a name prefix. (NXdata): exists: recommended (NXprocess): @@ -1409,13 +1371,10 @@ NXem(NXobject): # relevant research result post-processed for specific community methods # but normalized in its representation ready to be consumed for # research data management systems - ROI(NXobject): - nameType: any + roiID(NXroi): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: - - | - A region-of-interest analyzed either during or after the session for which specific - processed data are available. Instances should use roi as a name prefix. - | xref: spec: EMglossary @@ -1603,1811 +1562,3 @@ NXem(NXobject): # see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0a9138bae87afefffa5a84c62a07d8659a230c440064396310411a2fc79e1f14 -# -# -# -# -# -# Application definition for normalized representation of electron microscopy research. -# -# This application definition is a comprehensive example for a general description -# with which to normalize specific (meta)data collected from the research field -# of electron microscopy -# -# NXem is designed to be used for documenting experiments or computer simulations in which -# controlled electron beams are used for studying electron-beam matter interaction to explore -# physical mechanisms and phenomena or to characterize materials with an electron microscope. -# -# -# -# -# -# -# -# -# -# -# The configuration of the software that was used to generate this NeXus file. -# -# -# -# A collection of all programs and libraries that are considered as relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific set -# of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# Instances can also be used to document the modules and libraries that -# are offered by the computational environment such as those parsed -# from conda or python virtualenv environments. -# -# -# -# -# -# -# -# -# -# Alias (short name) which scientists can use to refer to this experiment. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into the field. The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. -# -# -# -# -# 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 - use this start_time field. -# -# Often though it is useful to specify a time interval via setting both a start_time -# and an end_time because this enables software tools and users to collect a -# more detailed bookkeeping of the experiment. -# -# Users should be aware though that even using only start_time and end_time -# may not be sufficient to infer how long the experiment took or for how long -# data were acquired. To bookkeep more fine-grained timestamps over the -# course of the experiment is possible with start_time and end_time fields -# of respective :ref:`NXevent_data_em` instances. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included when -# the microscope session ended. -# -# See docstring of the start_time field to see how to use the -# start_time and end_time together. -# -# -# -# -# -# Collection of serialized resources associated with the experiment. -# -# An example how to use this set is to document from which files in formatting -# of technology partners, the (meta)data in an instance of NXem were filled with -# during parsing to NeXus. -# -# -# -# -# -# -# -# -# Information about persons who performed or were involved in the microscope -# session or simulation run. -# -# Examples could be to put here the principle investigator who performed this -# experiment or students who performed simulations to name but a few. -# Adding multiple users if relevant is recommended. -# -# The protection of personal data by laws is in different stages of development -# and strictness. Therefore, the existence of user data has not been made -# required. -# -# Instances should use user as a name prefix. -# -# -# -# -# -# -# Given (first) name and surname. -# -# -# -# -# Name of the affiliation at the point in time when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address at the point in time when the experiment was performed. -# -# Writing the most permanently used email is recommended. -# -# -# -# -# Telephone number at the point in time when the experiment was performed. -# -# -# -# -# User role at the point in time when the experiment was performed. -# -# Examples are technician operating the microscope, student, postdoc, -# principle investigator, or guest. -# -# -# -# -# -# A physical entity which contains material intended to be investigated. -# Sample and specimen are treated as de facto synonyms. -# Samples can be real or virtual ones as annotated via is_simulation. -# -# The suggested best practice is to call this group sample. In those cases when -# multiple samples need to be grouped inside one entry, these SAMPLE groups -# should be named using the prefix sample followed an index starting from 1, i.e. -# (sample1, sample2). -# -# There are at least two strategies how to store (meta)data when one analyzes multiple -# samples - not different ROIs on a single sample though - in one session. -# -# One strategy is to store each sample and its results under an own NXem/ENTRY. -# This is one of the most frequent use cases as during most sessions typically only a -# single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. -# -# If multiple samples are investigated storing each of them in an own ENTRY group eventually will -# demand an unnecessary duplication though of many details about the instrument. -# -# This can be avoided by using another strategy how to store all samples and their results. -# Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, -# like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., -# i.e. instances should use sample as a name prefix. -# -# In this case though the collection of events demands to use identifier_sample to state clearly -# for which of the samples loaded the (characterization) event was detected. -# -# This concept is related to term `Specimen`_ of the EMglossary standard. -# -# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 -# -# -# -# Qualifier whether the sample is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# -# -# -# -# -# -# -# -# Ideally, (globally) unique persistent identifier which distinguishes this sample from all others -# and especially the predecessor/origin from where that sample was cut. The terms sample -# and specimen are here considered as exact synonyms. -# -# This field must not be used for an alias for the sample! Instead, use name. -# -# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve -# the specific sample, whose results are stored by this :ref:`NXentry` instance because a single -# NXentry should be used for the characterization of a single specimen. -# -# Details about the specimen preparation should be stored in resources referring to identifier_parent. -# -# -# -# -# -# Identifier of the sample from which the sample was cut or the string *None*, -# i.e. the parent to this sample. -# -# The purpose of this field is to support functionalities for tracking -# sample provenance in a research data management system. -# -# -# -# -# -# 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 timestamp when -# the measured specimen surface was actively prepared. Ideally, this matches -# the last timestamp that is mentioned in the digital resource pointed to by -# identifier_parent. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is especially -# required for material that is sensitive to the environment such as specimens that were -# charged with fast diffusing elements or short-lived radioactive tracers. -# -# Additional time stamps prior to preparation_date should better be placed in resources -# which describe but do not pollute the description here with prose. Resolving these -# connected metadata is considered as within the responsibility of the -# research data management system and not the a NeXus file. -# -# -# -# -# An alias used to refer to the specimen to please readability for humans. -# -# -# -# -# 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 research data management systems an opportunity -# to parse the relevant elements without having to interpret these from the resources -# pointed to by identifier_parent or walk through eventually deeply nested groups in -# individual data instances. -# -# -# -# -# (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 typically 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 a region-of-interest within connection to individual :ref:`NXevent_data_em` -# instances can provide a cleaner description of the relevant details -# why one may wish to store the density of the specimen. -# -# -# -# -# Discouraged free-text field to provide further detail. -# -# -# -# -# -# The conventions used when reporting crystal orientations. -# We follow the best practices of the Material Science community -# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin. -# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parametrizations/representations according -# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Location of the origin of the processing_reference_frame. -# -# It is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the specifically named :ref:`NXsample` instance(s) for -# which these conventions apply (e.g. /entry1/sample1). -# -# -# -# -# -# -# -# Location of the origin of the sample_reference_frame. -# -# It is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use detector_reference_frame as a name prefix. -# -# -# -# Reference to the specifically named :ref:`NXdetector` instance for -# which these conventions apply (e.g. /entry1/instrument/detector1). -# -# Instances should use detector_reference_frame as a name prefix. -# -# -# -# -# -# -# -# Location of the origin of the detector_reference_frame. -# -# If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the control program used for operating the microscope. -# -# Instances should use control_software as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use lens as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use aperture as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use monochromator as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use biprism as a name prefix. -# -# -# -# -# -# -# -# -# -# Instances should use phaseplate as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# Instances should use beam as a name prefix. -# -# -# -# -# Instances should use deflector as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use lens as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use aperture as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use monochromator as a name prefix. -# -# -# -# -# -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# Instances should use beam as a name prefix. -# -# -# -# -# Instances should use deflector as a name prefix. -# -# -# -# -# -# Instances should use detector as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use pump as a name prefix. -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# -# -# This group should be used to store all event-related (meta)data, -# which are typically measured datasets like images and spectra. -# To avoid that static instrument-related metadata need to be stored -# repetitively the NXem application definitions splits the storage of the -# dynamic (meta)data that typically change for each image and spectrum -# from the static one. -# -# -# -# Instances should use event as a name prefix. -# -# -# -# -# -# -# -# Instances should use image as a name prefix. -# Each NXimage instance must use only one image or stack instance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use spectrum as a name prefix. -# Each NXspectrum instance must use only one spectrum or stack instance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use lens as a name prefix. -# -# -# -# -# -# Instances should use aperture as a name prefix. -# -# -# -# Descriptor for the aperture setting 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 users. -# -# -# -# -# -# -# Instances should use monochromator as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# Instances should use tableau as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# Instances should use beam as a name prefix. -# -# -# -# -# Instances should use deflector as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# Instances should use lens as a name prefix. -# -# -# -# -# -# Instances should use aperture as a name prefix. -# -# -# -# Descriptor for the aperture setting 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 users. -# -# -# -# -# -# Instances should use monochromator as a name prefix. -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# Instances should use beam as a name prefix. -# -# -# -# -# Instances should use deflector as a name prefix. -# -# -# -# -# -# Instances should use detector as a name prefix. -# -# -# -# Operation mode of the detector as displayed by the control software. -# -# -# -# -# -# -# -# -# -# Instances should use sensor as a name prefix. -# -# -# -# -# Instances should use actuator as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# Nominal current of the heater. -# -# -# -# -# Nominal voltage of the heater. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Possibility for documenting a set of simulations of electron beam matter interaction. -# -# Instances should use simulation as a name prefix. -# -# -# -# The program with which the simulation was performed. -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# Configuration of the simulation -# -# -# -# -# Results of the simulation -# -# -# -# -# -# Description of the volume of interaction between of particle-matter interaction. -# -# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam -# interaction simulations can be used to qualify and (or) quantify the shape of -# the interaction volume. Results of such simulations can be summary statistics -# or single-particle-resolved sets of trajectories. -# -# Explicit or implicit descriptions of the geometry of this -# interaction volume 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 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 flux through -# an imaginary control surface (the iso-surface) 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>`_ -# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ -# -# Instances should use interaction_volume as a name prefix. -# -# -# -# -# -# -# -# -# -# A region-of-interest analyzed either during or after the session for which specific -# processed data are available. Instances should use roi as a name prefix. -# -# This concept is related to term `Region Of Interest`_ of the EMglossary standard. -# -# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 -# -# -# -# -# -# Instances should use image as a name prefix. -# Each NXimage instance must use only one image or stack instance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use phase as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index 3292b657f9..843372336e 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -46,7 +46,7 @@ NXem_calorimetry(NXobject): Name of the program whereby this config file was created. program(NX_CHAR): \@version(NX_CHAR): - environment(NXobject): + environment(NXcollection): exists: recommended doc: | Programs and libraries representing the computational environment @@ -239,305 +239,3 @@ NXem_calorimetry(NXobject): background_subtraction(NXprocess): exists: optional sequence_index(NX_POSINT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ac8d97a8c318bd93e2c3c40f0804037d8d3d689d2ab0dca1ffcd370a8060f0a0 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of diffraction pattern. -# -# -# -# -# Number of radial integration bins. -# -# -# -# -# Number of coordinates along i axis. -# -# -# -# -# Number of coordinates along j axis. -# -# -# -# -# Application definition for minimal example in-situ calorimetry. -# -# TODO: -# -# * What is the technique about. -# * General context. -# * Literature references. -# -# -# -# -# -# -# -# -# -# -# -# Details about performance, profiling, etc. -# -# -# -# -# -# -# -# Name of the program whereby this config file was created. -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# Qualifier whether the sample is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources. -# -# -# -# -# -# -# -# -# Reference to the resource which stores acquired pattern from the -# experiment or simulation that are analyzed in this workflow. -# -# Can refer to the original EMD or MRC files or the parsed NXem -# in RDM e.g. NOMAD OASIS. -# -# -# -# -# -# -# -# Reference to the resource which stores actuator log file from the experiment. -# -# -# -# -# -# -# -# Configuration file that was used for parametrizing this analysis workflow. -# -# -# -# -# -# -# -# Assumptions and computations whereby timestamping data from -# the detector and actuator (e.g. heating chip) were synchronized. -# -# -# -# -# ISO8601 with local time zone reference timestamp that tells -# with which delta_time can be converted in timestamp. -# The reference timestamp is defined as the time when the -# actuator started acting on the sample. -# -# Time differences to this timestamp when correlated signals such -# as diffraction pattern matching with a specific state of the sample -# (e.g. obtained temperature via the actuator) are reported through -# delta_time. -# -# -# -# -# -# -# -# -# -# Time difference to start_time. -# -# Collecting diffraction pattern also takes some time. -# It is assumed that the acquisition time for each pattern is -# substantial shorter than the time it takes the actuator to -# cause a change in stimulus (e.g. temperature). -# -# -# -# -# -# -# -# -# -# Computation of the centre for each pattern using e.g. a Circular Hough -# Transformation. -# -# -# -# -# -# Computed centre for each pattern. -# -# -# -# -# -# -# -# -# -# -# Elliptical distortion correction as a step when computing the centre for -# patterns. -# -# -# -# -# -# Computed centre for each pattern. -# -# -# -# -# -# -# -# -# -# -# Integrated diffraction pattern intensity as a function of radial distance from the centre -# azimuthally integrated as a function of time. -# -# -# -# -# -# The integrated intensities: -# -# * result_with_background -# * result_without_background -# -# -# -# -# -# -# -# -# Integrated intensity as a function of time and the radial distance from the -# pattern centre. -# -# -# -# -# -# -# -# -# -# Identifier for each pattern. -# -# -# -# -# -# -# -# -# Positions in reciprocal space. -# -# -# -# -# -# -# -# -# -# Time since start of the in-situ experiment -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_measurement.yaml b/contributed_definitions/nyaml/NXem_measurement.yaml new file mode 100644 index 0000000000..183781ce9c --- /dev/null +++ b/contributed_definitions/nyaml/NXem_measurement.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for ################ +type: group +NXem_measurement(NXobject): diff --git a/contributed_definitions/nyaml/NXem_simulation.yaml b/contributed_definitions/nyaml/NXem_simulation.yaml new file mode 100644 index 0000000000..c23de85afb --- /dev/null +++ b/contributed_definitions/nyaml/NXem_simulation.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class for documenting a set of simulations of electron beam-matter interaction. +type: group +NXinteraction_volume_em(NXobject): + (NXprogram): + (NXparameters): + (NXprocess): + (NXdata): diff --git a/contributed_definitions/nyaml/NXevent_em.yaml b/contributed_definitions/nyaml/NXevent_em.yaml new file mode 100644 index 0000000000..38fb866dce --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_em.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class for grouping instances of :ref:`NXevent_data_em`. + + This group should be used to bundle all event-related (meta)data + and measured data including images and spectra. +type: group +NXevent_em(NXobject): + (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml new file mode 100644 index 0000000000..88451ccfbc --- /dev/null +++ b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml @@ -0,0 +1,33 @@ +category: base +doc: | + Base class to group data and descriptions of the volume of interaction for particle-matter interaction. + + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle-resolved sets of trajectories. + + Explicit or implicit descriptions of the geometry of this + interaction volume 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 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 flux through + an imaginary control surface (the iso-surface) 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. `_ + * `J. F. Ziegler et al. `_ + +type: group +NXinteraction_volume_em(NXobject): + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 0bb68c9432..f6ca8ea682 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -203,7 +203,7 @@ NXmicrostructure(NXobject): chemical_symbol(NX_CHAR): composition(NX_FLOAT): composition_error(NX_FLOAT): - phases(NXobject): + phases(NXmicrostructure_feature): doc: | Different (thermodynamic) phases can be distinguished for the region-of- interest. @@ -214,7 +214,7 @@ NXmicrostructure(NXobject): (NXphase): doc: | Instances should use phase as a prefix. - crystals(NXobject): + crystals(NXmicrostructure_feature): doc: | One- or two-dimensional projections, or three-dimensional representations of crystals. @@ -305,7 +305,7 @@ NXmicrostructure(NXobject): orientation(NXrotations): doc: | Possibility to store the mean orientation of the grain. - interfaces(NXobject): + interfaces(NXmicrostructure_feature): doc: | One- or two-dimensional projections or three-dimensional representation of interfaces between crystals as topological entities equivalent to dual_junctions. @@ -435,7 +435,7 @@ NXmicrostructure(NXobject): The surface area of all interfaces. dimensions: dim: (n_i,) - triple_junctions(NXobject): + triple_junctions(NXmicrostructure_feature): doc: | Projections or representations of junctions at which three interfaces meet. @@ -556,7 +556,7 @@ NXmicrostructure(NXobject): Respective cut-off criteria need to be specified. dimensions: dim: (n_tj,) - quadruple_junctions(NXobject): + quadruple_junctions(NXmicrostructure_feature): doc: | Quadruple junctions as a region where four crystals meet. @@ -678,902 +678,3 @@ NXmicrostructure(NXobject): Non-intrinsic mobility of each quadruple_junction. dimensions: dim: (n_qj,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9cc695e350320f25291b2bc291347defc2e4d947dd53e01580f21cb7e8f40793 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of crystals or their projections -# -# -# -# -# The number of interfaces or their projections -# -# -# -# -# The number of triple junctions or their projections -# -# -# -# -# The number of quadruple junctions or their projections -# -# -# -# -# -# The number of one-dimensional crystal projections -# -# -# -# -# The number of one-dimensional interface projections -# -# -# -# -# -# The number of two-dimensional crystal projections -# -# -# -# -# The number of two-dimensional interface projections -# -# -# -# -# The number of two-dimensional triple line projections -# -# -# -# -# The number of two-dimensional line defect projections -# -# -# -# -# -# The number of crystals (grain and sub-grain are exact synonyms for crystal). -# -# -# -# -# The number of interfaces (grain boundary and phase boundary are subclasses of -# interfaces). -# -# -# -# -# The number of triple junctions (triple line is a exact synonym for triple -# junction, triple point is projection of a triple junction). -# -# -# -# -# The number of quadruple junctions. -# -# -# -# -# -# The dimensionality of the representation that needs to match the value for -# configuration/dimensionality -# -# -# -# -# Base class to describe a microstructure, its structural aspects, associated descriptors, properties. -# -# Whether one uses a continuum or atomic scale description of materials, these are always a model only of -# the true internal structure of a material. Such models are useful as they enable a coarse-graining and -# categorizing of properties and representational aspects from which measured or simulated descriptions -# can be correlated with properties, i.e. descriptor values. The base class here can be used to describe -# the structural aspect of a region-of-interest for a specimen that was investigated or a computer -# simulation that was performed for a virtual specimen. -# -# Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, -# the characterized microstructure may not turn out to be the same structure as of the untreated -# sample from which the region-of-interests on the specimen were sampled. -# -# Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' -# structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually -# always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation -# (projection) of the characterized material volume. Often materials are characterized only for specific states -# or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. -# This is typically a compromise between the research questions and technical surplus practical limitations. -# -# The term microstructural feature covers here crystals and all sorts of crystal defects within the material -# (interfaces, triple junctions, dislocations, pores, etc.). -# A key challenge with the description of representations and properties of such microstructural features is that -# they can be represented and view as features with different dimensionality. Furthermore, combinations of features of -# different dimensionality are frequently expected to be documented with intuitive naming conventions when -# flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based -# on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. -# -# NXmicrostructure is an attempt to standardize these descriptions stronger. -# -# For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and -# junctions of different types of crystal defects. The term grain describes a contiguous region of material that is -# delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though -# a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. -# In this base class we use the term and respective group crystals though for single crystals and grains. -# The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume -# that the internal structure of these grains can be described with homogenized effective properties. -# If alternatively the individual structural crystalline or features of this grain should be distinguished -# it is useful to instantiate these as individual instances of crystals. -# -# Grain boundaries and phase boundaries are two main categories of interfaces. -# A grain boundary delineates two regions with similar crystal structure and phase but different orientation. -# A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically -# but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two -# phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments -# but considers that atomic segregation is an equally important structural aspect to consider when classifying grain -# boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties -# is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and A. Sutton and R. W. Baluffi, -# Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. -# -# Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in -# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. -# Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, -# or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material -# properties or affect material properties. -# -# Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values -# which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms -# are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional -# description such as a triple line or a triple point as the projection of a line. Therefore, different representations can -# be used to describe the location, shape, and structure of such defect. -# -# This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, -# volumetric, patch, line, and point like features that can serve as examples for future extension. -# -# As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable -# objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations -# as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- -# triple-line junctions, likewise dislocations form own junctions. -# -# The description took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ -# and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. -# -# Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined -# on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers -# for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. -# -# -# -# -# Discouraged free-text field for leaving comments -# -# -# -# -# ISO8601 with offset to local time zone included when a timestamp is required. -# -# -# -# -# Measured or simulated physical time stamp for this microstructure snapshot. -# Not to be confused with wall-clock timing or profiling data. -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# Group where to store details about the configuration and parameterization of algorithms -# used whereby microstructural features were identified. -# -# -# -# Dimensionality of Euclidean space in which the analysis is performed. -# -# This field can be used e.g. by a research data management system to identify -# if the description specifies one-, two-, or three-dimensional microstructural representations. -# -# -# -# -# -# -# -# -# -# Algorithm whereby interfaces between crystals were reconstructed. -# -# * Disorientation clustering groups nearby material points based on their crystallographic disorientation -# * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ -# * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ -# -# -# -# -# -# -# -# -# -# -# -# Threshold to define at which disorientation angle to assume two crystalline regions have a significant -# orientation difference that warrants to assume that there exists an interface between the two regions. -# -# -# -# -# The program with which the microstructure was reconstructed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The chemical composition of this microstructure (region). -# -# -# -# -# -# -# -# -# -# -# Different (thermodynamic) phases can be distinguished for the region-of- -# interest. -# -# -# -# First identifier whereby to identify phases implicitly. -# -# -# -# -# Instances should use phase as a prefix. -# -# -# -# -# -# One- or two-dimensional projections, or three-dimensional representations of crystals. -# -# An example for a volume bounded by other crystal defects. Crystals can be grains of -# different phases, precipitates, dispersoids; there are many terms used specifically in -# the materials engineering community. -# -# Typically, crystals are measured on the surface of a sample via optical or electron microscopy. -# Using X-ray diffraction methods crystals can be observed in bulk specimens. -# -# Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. -# In rare cases the volume bounded gets represented using constructive solid geometry approaches. -# -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) -# * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# How many crystals are distinguished. -# -# Crystals are listed irrespective of the phase to which these are assigned. -# -# -# -# -# How many phases are distinguished. -# -# Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. -# -# -# -# -# First identifier whereby to identify crystals implicitly. -# -# -# -# -# Identifier whereby to identify each crystal explicitly. -# -# -# -# -# -# -# -# Identifier whereby to identify phase for each crystal explicitly. -# -# -# -# -# -# -# -# -# True, if the feature makes contact with the edge of the ROI. -# False, if the feature does not make contact with the edge of the ROI. -# -# -# -# -# -# -# -# Average disorientation angle for each crystal between individual orientations -# of that crystal evaluated as a summary statistic for all probed positions vs the -# average disorientation of that crystal. -# -# -# -# -# -# -# -# Length of each crystal -# -# -# -# -# -# -# -# Area of each crystal. -# -# -# -# -# -# -# -# Volume of each crystal -# -# -# -# -# -# -# -# Possibility to store the mean orientation of the grain. -# -# -# -# -# -# One- or two-dimensional projections or three-dimensional representation of interfaces -# between crystals as topological entities equivalent to dual_junctions. -# -# An example for a surface defect. Most important are interfaces such as grain and phase boundaries -# but factually interfaces also exist between the environment and crystals exposed at the -# surface of the specimen or internal surfaces like between crystals, cracks, or pores. -# -# Interfaces are typically reported as discretized features. For interface projections on the 2D plane -# these are most frequently polyline segments. For interface patches in 3D these are most frequently -# triangulations. Descriptions with continuous functions are seldom used unless simplified configurations -# are studied in modeling and theoretical studies. -# -# When using discretizations the individual interface segments need to be distinguished from the interfaces -# themselves. Consequently, there are two sets of indices. -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) -# * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks -# (like in computer simulations or 3D experiments) -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# How many interfaces are distinguished. -# -# -# -# -# First identifier whereby to identify interfaces implicitly. -# -# -# -# -# Identifier whereby to identify each interface explicitly. -# -# An array with as many entries as interfaces or their projections. -# -# -# -# -# -# -# -# -# Set of pairs of indices_crystal values, for each interface one value pair. -# -# An array with as many pairs as interfaces or their projections. -# -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# Set of pairs of indices_phase values, for each interface one value pair. -# -# An array with as many pairs as interfaces or their projections. -# -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional -# projections. The latter situation applies typically for characterization with electron -# microscopy. -# -# In the case of a two-dimensional projection interfaces are interface traces. These have -# two terminating junctions. In three dimensions though the interface is a surface patch -# that is bounded by multiple triple lines. -# -# Number of triple_junctions adjoining each interface. This array resolves the number of -# values along the second dimension for the field indices_triple_junctions. -# -# -# -# -# -# -# -# Set of pairs of indices_triple_junction for each interface. -# -# An array with as many tuples of pairs to describe -# all junctions about all interfaces. -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# True, if the interface makes contact with the edge of the ROI. -# False, if the interface does not make contact with the edge of the ROI. -# -# -# -# -# -# -# -# Gibbs free surface energy for each interface. -# -# -# -# -# -# -# -# Non-intrinsic mobility of each interface. -# -# -# -# -# -# -# -# The length of each interface if only projections are available. -# -# This is not necessarily the same as the length of the individual -# polyline segments whereby the interface is discretized. -# -# -# -# -# -# -# -# The surface area of all interfaces. -# -# -# -# -# -# -# -# -# Projections or representations of junctions at which three interfaces meet. -# -# An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, -# or junctions observed between crystals (at the specimen surface exposed to an environment) -# (including wetting phenomena) or inside the specimen (crack, pores). -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_polyline` for a two-dimensional representation as only a projection is available -# * :ref:`NXcg_polygon` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution -# and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles -# * :ref:`NXcg_polyhedron` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# Number of triple junctions. -# -# -# -# -# First identifier to identify triple junctions implicitly. -# -# -# -# -# Identifier to identify each triple junction explicitly. -# -# -# -# -# -# -# -# -# Set of identifier for positions whereby to identify the location of each -# junction. -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# Explicit positions. -# -# -# -# -# -# -# -# -# Set of tuples of identifier of crystals connected to the junction for each -# triple junction. -# -# -# -# -# -# -# -# -# -# Set of tuples of identifier of interfaces connected to the junction for each -# triple junction. -# -# -# -# -# -# -# -# The specific interface identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for polyline segments connected to the junction for -# each triple junction. -# -# -# -# -# -# -# -# The specific indices_polyline whereby to resolve ambiguities. -# -# -# -# -# -# -# True, if the triple line makes contact with the edge of the ROI. -# False, if the triple line does not make contact with the edge of the ROI. -# -# -# -# -# -# -# -# Specific line energy of each triple junction -# -# -# -# -# -# -# -# Non-intrinsic mobility of each triple junction. -# -# -# -# -# -# -# -# The length of each triple junction. -# -# This is not necessarily the same as the length of the individual -# polyline segments whereby the junction is discretized. -# -# -# -# -# -# -# -# The volume about each triple junction. -# -# Respective cut-off criteria need to be specified. -# -# -# -# -# -# -# -# -# Quadruple junctions as a region where four crystals meet. -# -# An example for a point (like) defect. -# -# Thermodynamically such junctions can be unstable. -# Specifically when discretizations are used in simulations -# that do not address the thermodynamics of and splitting characteristics -# of junctions in cases when more than four crystals meet, it is possible -# that so-called higher-order junctions are observed. -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point` -# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# Number of quadruple junctions. -# -# -# -# -# First identifier to identify quadruple junctions implicitly. -# -# -# -# -# Identifier to identify each quadruple junction explicitly. -# -# -# -# -# -# -# -# -# Set of identifier for positions whereby to identify the location of each -# junction. -# -# -# -# -# -# -# The specific point identifier whereby to resolve ambiguities. -# -# -# -# -# -# Explicit positions. -# -# -# -# -# -# -# -# -# -# Set of tuples of identifier of crystals connected to the junction for each -# junction. -# -# -# -# -# -# -# -# The specific identifier to instances of crystal identifiers whereby to resolve -# ambiguities. -# -# -# -# -# -# Set of tuples of identifier of interfaces connected to the junction for each -# junction. -# -# -# -# -# -# -# -# The specific identifier to instances of interface identifiers whereby to resolve -# ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for triple junctions connected to the junction for -# each quadruple junction. -# -# -# -# -# -# -# -# The specific identifier to instances of triple junction identifiers whereby to -# resolve ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for phases of crystals connected to the junction for -# each quadruple junction. -# -# -# -# -# -# -# -# The specific identifier to instances of phase identifier whereby to resolve -# ambiguities. -# -# -# -# -# -# -# True, if the junction makes contact with the edge of the ROI. -# True, if the junction does not make contact with the edge of the ROI. -# -# -# -# -# -# -# -# Energy of the quadruple_junction as a defect. -# -# -# -# -# -# -# -# Non-intrinsic mobility of each quadruple_junction. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_feature.yaml b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml new file mode 100644 index 0000000000..68b3a52304 --- /dev/null +++ b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for documenting structuring features of a microstructure. +type: group +NXmicrostructure_feature(NXobject): diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index 9f8c22ca95..903a0e3550 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -36,7 +36,7 @@ NXmicrostructure_gragles_config(NXobject): \@version: \@url: exists: recommended - environment(NXobject): + environment(NXcollection): exists: optional doc: | Programs and libraries representing the computational environment @@ -71,7 +71,7 @@ NXmicrostructure_gragles_config(NXobject): Edge_length is the length of the entire domain along its edge not the length of the Wigner-Seitz cell about each material point! - sampling(NXobject): + sampling(NXparameters): doc: | Configuration when snapshots of the system should be taken. @@ -92,7 +92,7 @@ NXmicrostructure_gragles_config(NXobject): # 31 no more sampling # 1 - simulation_control(NXobject): + simulation_control(NXparameters): doc: | Configuration when the simulation should be stopped in a controlled manner. Whichever criterion is fulfilled first triggers the controlled stop of @@ -106,7 +106,7 @@ NXmicrostructure_gragles_config(NXobject): unit: NX_UNITLESS doc: | The simulation stops if more iterations than this criterion have been computed. - numerics(NXobject): + numerics(NXparameters): doc: | Configuration of numerical details of the solver. @@ -135,7 +135,7 @@ NXmicrostructure_gragles_config(NXobject): # 1 # 0, E_ITERATIVE, 1, E_SQUARES # 0.0 # - grid_coarsement(NXobject): + grid_coarsement(NXparameters): doc: | Configuration of the grid coarsement algorithm whereby the representation of the system is continuously rediscretized such that on average grains @@ -166,7 +166,7 @@ NXmicrostructure_gragles_config(NXobject): # 3 # 2 # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated - grain_boundary_mobility(NXobject): + grain_boundary_mobility(NXparameters): doc: | Physically-based model of the assumed mobility of the grain boundaries. @@ -204,7 +204,7 @@ NXmicrostructure_gragles_config(NXobject): unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_3`. Typically 9. - grain_boundary_energy(NXobject): + grain_boundary_energy(NXparameters): doc: | Physically-based model of the assumed grain boundary surface energy. @@ -233,14 +233,14 @@ NXmicrostructure_gragles_config(NXobject): # 0.01 # - curvature_driving_force(NXobject): + curvature_driving_force(NXparameters): doc: | A continuum-scale curvature of an interface causes the interface to migrate towards the center of the curvature radius. is_active(NX_BOOLEAN): doc: | If true the curvature_driving_force is considered, otherwise it is not. - stored_elastic_energy(NXobject): + stored_elastic_energy(NXparameters): doc: | A continuum-scale difference of the stored elastic energy in dislocation configurations across a grain boundary can exert a driving force on the @@ -254,7 +254,7 @@ NXmicrostructure_gragles_config(NXobject): doc: | Prefactor :math:`0.5Gb^2` that factorizes the average stored elastic energy per length dislocation line. - magnetic_field(NXobject): + magnetic_field(NXparameters): doc: | In case of an applied magnetic field, a difference of the magnetic susceptibility can exert a driving force on the grain boundary such that @@ -265,7 +265,7 @@ NXmicrostructure_gragles_config(NXobject): # MagneticField.xml # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml - triple_line_mobility(NXobject): + triple_line_mobility(NXparameters): doc: | A triple line mediates the atomic arrangement differences between three interface patches. Therefore, the triple line is a defect that may not @@ -282,375 +282,3 @@ NXmicrostructure_gragles_config(NXobject): # 1 # 1 25 # - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2937adc715e78fe6bbf5ad57d09e76ad2aa4dd3eb9782c8ddacd0bd6bffc4e80 -# -# -# -# -# -# -# Application definition for configuring GraGLeS. -# -# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations -# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. -# CPU parallelization is achieved with OpenMP. -# -# The code has been implemented by C. Mießen in the group of G. Gottstein -# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. -# -# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# From which file should the microstructure be instantiated. -# -# -# -# -# -# -# -# -# The formulation of mean curvature flow in the GraGLeS model is scale invariant. -# Therefore, the discretization has to be scaled to the actual physical length -# of the simulation domain (ve, ROI). -# For GraGLeS the discretization is always a square or cubic axis-aligned -# bounding box with a regular tiling into material points -# (either squares or cubes respectively). -# -# Edge_length is the length of the entire domain along its edge not -# the length of the Wigner-Seitz cell about each material point! -# -# -# -# -# -# Configuration when snapshots of the system should be taken. -# -# Keep in mind that essentially geometry snapshot data store the -# polylines and polyhedra of all grains which can take substantial disk -# space. -# -# -# -# Generate a snapshot of the properties of the grains to follow -# the evolution of the microstructure every :math:`n`-th iteration. -# Setting zero causes that no property snapshots are taken. -# -# -# -# -# Generate a snapshot of the geometry of the entire grain boundary network -# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. -# -# -# -# -# -# -# Configuration when the simulation should be stopped in a controlled manner. -# Whichever criterion is fulfilled first triggers the controlled stop of -# and termination of GraGLeS. -# -# -# -# The simulation stops if the total number of grains -# becomes smaller than this criterion. -# -# -# -# -# The simulation stops if more iterations than this criterion have been computed. -# -# -# -# -# -# Configuration of numerical details of the solver. -# -# -# -# -# Which type of convolution kernel and model is used. -# -# -# -# -# -# -# -# -# -# Constant to calibrate the real time scaling of the simulation. -# -# -# -# -# -# -# Configuration of the grid coarsement algorithm whereby the representation -# of the system is continuously rediscretized such that on average grains -# are discretized with discretization many material points along each -# direction. -# -# Grid coarsement can reduce the computational costs substantially although -# it cannot be ruled out completely that the rediscretizing may have an effect -# on the system evolution. Without grid coarsement the total number of material -# points to consider stays the same throughout the simulation. -# -# -# -# Number of material points along each direction to discretize the -# average grain. The larger this value is chosen the finer the curvature -# details are that can be resolved but also the longer the simulation -# takes. -# -# -# -# -# If true grid coarsement is active, otherwise it is not. -# -# -# -# -# Fraction how strongly the number of grains has to reduce -# to trigger a grid coarsement step in an iteration. -# -# -# -# -# -# -# Physically-based model of the assumed mobility of the grain boundaries. -# -# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent -# especially as grain boundaries in reality are decorated with defects as a consequence of which -# the actual mobility is a combination of the mobility of the individual defects and the attached -# boundary patches. Grain boundaries have different degrees of microscopic freedom. -# Therefore, their mobility follows a distribution. -# -# -# -# -# Fundamental model how :math:`m` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. -# -# -# -# -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. -# -# -# -# -# -# Mobility scaling factor :math:`c_2`. Typically 5. -# -# -# -# -# Mobility scaling factor :math:`c_3`. Typically 9. -# -# -# -# -# -# Physically-based model of the assumed grain boundary surface energy. -# -# Like for the grain boundary mobility, defects cause a distribution of energies for the -# patches of which the boundary is composed. In practice a too complicated dependency -# of the energy and mobility model is observed as a function of the type and chemical -# decoration of the defects. Therefore, simplifying assumptions are typically made. -# -# -# -# Fundamental type of assumption if energies are considered isotropic or not. -# -# -# -# -# -# -# -# -# Fundamental model how :math:`\gamma` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# Mean grain boundary surface energy that is assumed a function of the -# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. -# This value factorizes the curvature_driving_force model. -# -# -# -# -# -# -# A continuum-scale curvature of an interface causes the interface to -# migrate towards the center of the curvature radius. -# -# -# -# If true the curvature_driving_force is considered, otherwise it is not. -# -# -# -# -# -# A continuum-scale difference of the stored elastic energy in dislocation -# configurations across a grain boundary can exert a driving force on the -# grain boundary such that the boundary migrates into the volume with the -# higher stored elastic energy. -# -# -# -# If true the dislocation_driving_force is considered, otherwise it is not. -# -# -# -# -# Prefactor :math:`0.5Gb^2` that factorizes the average -# stored elastic energy per length dislocation line. -# -# -# -# -# -# In case of an applied magnetic field, a difference of the magnetic -# susceptibility can exert a driving force on the grain boundary such that -# the boundary migrates into the volume with the higher magnetic energy. -# -# -# -# If true the magnetic_driving_force is considered, otherwise it is not. -# -# -# -# -# -# -# A triple line mediates the atomic arrangement differences between three -# interface patches. Therefore, the triple line is a defect that may not -# have the same mobility as adjoining grain boundaries and thus it may -# exert what can be conceptualized as a drag (resistance) to the motion -# of the adjoining interface patches. -# -# -# -# Assumed triple junction drag. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 8435313834..6dbb0ac6ca 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -33,7 +33,7 @@ NXmicrostructure_gragles_results(NXobject): \@version: \@url: exists: recommended - environment(NXobject): + environment(NXcollection): exists: optional doc: | Programs and libraries representing the computational environment @@ -41,23 +41,17 @@ NXmicrostructure_gragles_results(NXobject): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - sign_convention: - sample_reference_frame(NXcoordinate_system): - type: - handedness: - origin: - x_alias: - x_direction: - y_alias: - y_direction: - z_alias: - z_direction: - SPATIOTEMPORAL(NXobject): + sample_reference_frame(NXcoordinate_system): + type: + handedness: + origin: + x_alias: + x_direction: + y_alias: + y_direction: + z_alias: + z_direction: + SPATIOTEMPORAL(NXprocess): nameType: any doc: | Documentation of the spatiotemporal evolution @@ -66,7 +60,7 @@ NXmicrostructure_gragles_results(NXobject): # static quantities for which no change is modelled # the typical lean summary statistics flattened - summary_statistics(NXobject): + summary_statistics(NXprocess): doc: | Summary quantities which are the result of some post-processing of the snapshot data (averaging, integrating, interpolating) happening in for practical reasons though in while @@ -168,7 +162,7 @@ NXmicrostructure_gragles_results(NXobject): Simulated temperature for this snapshot. grid(NXcg_grid): exists: optional - crystal(NXobject): + crystal(NXmicrostructure_feature): representation: exists: recommended number_of_crystals(NX_UINT): @@ -191,7 +185,7 @@ NXmicrostructure_gragles_results(NXobject): dimensions: rank: 1 dim: (n_grains,) - interface(NXobject): + interface(NXmicrostructure_feature): exists: optional representation(NX_CHAR): exists: recommended @@ -221,311 +215,3 @@ NXmicrostructure_gragles_results(NXobject): dimensions: rank: 1 dim: (n_interfaces,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b7c1f435d6d4a86abd4a044cda9232a03cb36af47077afbfb4388b6fb0c30da0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of summary statistic log entries. -# -# -# -# -# Number of grains in the computer simulation. -# -# -# -# -# Number of interfaces in the computer simulation. -# -# -# -# -# Application definition for documenting results with GraGLeS. -# -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Documentation of the spatiotemporal evolution -# -# Instances should use spatiotemporal as a name prefix. -# -# -# -# -# Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening in for practical reasons though in while -# running the simulation. Place used for storing descriptors from continuum mechanics -# and thermodynamics at the scale of the entire ROI. -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# Evolution of the physical time not to be confused with wall-clock time or -# profiling data. -# -# -# -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# How many crystals are distinguished. -# Crystals are listed irrespective of the phase to which these are assigned. -# -# -# -# -# -# -# -# -# -# Which type of stress. -# -# -# -# -# -# -# -# Applied external stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of strain. -# -# -# -# -# Applied external strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of deformation gradient. -# -# -# -# -# -# -# -# Applied deformation gradient tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Applied external magnetic field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external electrical field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use microstructure as a name prefix. -# -# -# -# -# -# Simulated temperature for this snapshot. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# One pair of indices_crystal values for each interface. -# -# -# -# -# -# -# -# -# -# Mobility times surface energy density of the interface normalized -# to the maximum such product of the interface set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index bd66cbcfde..88fd1b3d2e 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -23,7 +23,7 @@ NXmicrostructure_imm_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_config] - roi(NXobject): + roi(NXparameters): doc: | The computational domain will be synthesized either as a square (for dimensionality = 2) or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is @@ -76,7 +76,7 @@ NXmicrostructure_imm_config(NXobject): # remove 0 all the time 0.00 # remove 0 all the time 0.00 # - component_analysis(NXobject): + component_analysis(NXparameters): exists: optional doc: | In texture research component analyses set on the idea that properties @@ -108,7 +108,7 @@ NXmicrostructure_imm_config(NXobject): dimensions: rank: 1 dim: (n_components,) - dislocation_distribution(NXobject): + dislocation_distribution(NXparameters): doc: | Dislocations are modelled as Rayleigh-distributed mean-field density that can differ between but is constant within grains and sub-grains. @@ -144,7 +144,7 @@ NXmicrostructure_imm_config(NXobject): dimensions: rank: 1 dim: (n_categories,) - orientation_distribution(NXprocess): + orientation_distribution(NXparameters): doc: | Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. Orientations of the sub-grains are sampled by scattering the orientation @@ -174,248 +174,3 @@ NXmicrostructure_imm_config(NXobject): # 0.00 # 1.00 # -# -# -# -# -# -# -# How many texture components are distinguished, minimum is 1. -# -# -# -# -# How many special texture components are distinguished if any. -# -# -# -# -# Number of discrete orientations that are distributed across the grains. -# -# -# -# -# Application definition for the configuration of the legacy (micro)structure generator -# developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# The computational domain will be synthesized either as a square (for dimensionality = 2) -# or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is -# discretized into material points using either square pixel or cubic voxel as the tessellating -# unit cells. -# -# -# -# Two-dimensional or three-dimensional simulation. -# -# -# -# -# -# -# -# -# Target value for the number of material points per equivalent -# discrete diameter of the arithmetic average sub-grain. -# -# -# -# -# Assumed space group of the material. -# -# -# -# -# -# -# -# -# -# -# Target value for the number of grains. The actual domain size and grid will be configured -# based on the choices for discretization, number_of_grains, and shape of these grains. -# -# -# -# -# Target value for the average number of sub-grains per grain. -# -# -# -# -# -# If available used to define the sequence of relative extent of grains along the y (first value) -# and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, -# the relative extent of the grains will be 1 one average along each axis (globulitic structure). -# -# -# -# -# -# -# -# -# -# In texture research component analyses set on the idea that properties -# of grains different based on orientation with certain regions in orientation -# space show similar trends like a different average dislocation density -# or orientation_spread. -# -# -# -# The first entry is always the null model None which means that an orientation -# is not categorized as a special component. Examples for special components are -# Dillamore, Copper, Cube, Y, P and Q. -# -# -# -# -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# Disorientation angle below which an orientation is categorized as one of the -# components. -# -# -# -# -# -# -# -# -# Dislocations are modelled as Rayleigh-distributed mean-field density that -# can differ between but is constant within grains and sub-grains. -# -# -# -# The minimum and the maximum dislocation density to distribute across grains. -# -# -# -# -# -# -# -# -# The minimum and the maximum dislocation density to distribute across sub-grains. -# -# -# -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the grains. -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the sub-grains. -# -# -# -# -# -# -# -# -# Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. -# Orientations of the sub-grains are sampled by scattering the orientation -# of the (parent) grain and with optional Rayleigh-distributed scatter. -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# The variance of the disorientation of the sub-grain to their parent grain. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index b04c88b809..2e2b8db213 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -36,7 +36,7 @@ NXmicrostructure_imm_results(NXobject): \@version(NX_CHAR): \@url(NX_CHAR): exists: recommended - environment(NXobject): + environment(NXcollection): exists: optional doc: | Programs and libraries representing the computational environment @@ -95,7 +95,7 @@ NXmicrostructure_imm_results(NXobject): \@long_name(NX_CHAR): doc: | Coordinate along x direction. - crystals(NXobject): + crystals(NXmicrostructure_feature): reference(NX_CHAR): number_of_crystals(NX_UINT): indices_crystal(NX_INT): @@ -136,198 +136,3 @@ NXmicrostructure_imm_results(NXobject): dimensions: rank: 1 dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84de7a5c34339e7ba2c442b56c8147b71755dc7858c3c1d1e84ba24757cb23da -# -# -# -# -# -# -# -# Number of material points along the edge of the square- or cube-shaped domain. -# -# -# -# -# Number of crystals. -# -# -# -# -# Application definition for the results of the legacy (micro)structure generator developed -# by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# Instances should use microstructure as a name prefix. -# -# -# -# -# -# -# Default plot showing the grid. -# -# -# -# -# -# -# -# Crystal identifier that was assigned to each material point. -# -# -# -# -# -# Material point barycenter coordinate along z direction. -# -# -# -# -# -# -# Coordinate along z direction. -# -# -# -# -# -# Material point barycenter coordinate along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Material point barycenter coordinate along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# True if the crystal is considered a sub-grain. -# False if the crystal is considered a grain. -# -# -# -# -# -# -# -# Bunge-Euler angle orientation of each crystal. -# -# -# -# -# -# -# -# -# Mean-field dislocation density as a measure of the stored elastic energy -# content that is stored in the dislocation network of this grain and related -# defects within each crystal. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 9737899695..3679e641d2 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -43,7 +43,7 @@ NXmicrostructure_kanapy_results(NXobject): \@version(NX_CHAR): \@url(NX_CHAR): exists: recommended - environment(NXobject): + environment(NXcollection): exists: optional doc: | Programs and libraries representing the computational environment @@ -109,7 +109,7 @@ NXmicrostructure_kanapy_results(NXobject): Coordinate along x direction. # add nodal positions as suggested in NXmicrostructure - crystals(NXobject): + crystals(NXmicrostructure_feature): reference(NX_CHAR): number_of_crystals(NX_UINT): number_of_phases(NX_UINT): @@ -138,202 +138,3 @@ NXmicrostructure_kanapy_results(NXobject): dimensions: rank: 2 dim: (c, 3) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 444427cf4a220a0d78a8b7fedc52c861453a6d449892b3799de4e74de372b927 -# -# -# -# -# -# -# -# Number of material points along the z axis of the domain. -# -# -# -# -# Number of material points along the y axis of the domain. -# -# -# -# -# Number of material points along the x axis of the domain. -# -# -# -# -# Number of crystals. -# -# -# -# -# Application definition for the microstructure generator kanapy from ICAMS Bochum. -# -# * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ -# -# A draft application definition to support discussion within the infrastructure use case IUC07 of the -# NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations -# of spatiotemporal microstructure evolution with scientific software from this community. -# -# -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# Instances should use microstructure as a name prefix. -# -# -# -# -# -# -# -# -# Default plot showing the grid. -# -# -# -# -# -# -# -# Crystal identifier that was assigned to each material point. -# -# -# -# -# -# Material point barycenter coordinate along z direction. -# -# -# -# -# -# -# Coordinate along z direction. -# -# -# -# -# -# Material point barycenter coordinate along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Material point barycenter coordinate along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Bunge-Euler angle orientation of each crystal. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index 8459edcee9..79187f804b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -128,7 +128,9 @@ NXmicrostructure_mtex_config(NXobject): inside_poly(NX_BOOLEAN): doc: | TODO with MTex developers - text_interpreter: + text_interpreter(NX_CHAR): + doc: | + TODO with MTex developers numerics(NXcollection): doc: | Miscellaneous settings relevant for numerics. diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index cef6e11cd3..cf8062e313 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -20,7 +20,7 @@ symbols: Number of sampled positions in orientation space. type: group NXmicrostructure_odf(NXprocess): - configuration(NXobject): + configuration(NXparameters): doc: | Details about the algorithm used for computing the ODF. crystal_symmetry_point_group(NX_CHAR): @@ -44,7 +44,7 @@ NXmicrostructure_odf(NXprocess): Resolution of the kernel. # specific values and typical results - kth_extrema(NXobject): + kth_extrema(NXprocess): doc: | Group to store descriptors and summary statistics for extrema of the ODF. extrema(NX_CHAR): @@ -81,7 +81,7 @@ NXmicrostructure_odf(NXprocess): dimensions: rank: 1 dim: (k,) - sampling(NXobject): + sampling(NXprocess): doc: | The ODF intensity values (weights) as sampled with a software. resolution(NX_NUMBER): @@ -153,230 +153,3 @@ NXmicrostructure_odf(NXprocess): dim: (n_varphi_two,) # \@long_name(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dbafdd60be3fa8ae011100f19bf78577fd2bb2379dc3aa898cbdbef5eebbc048 -# -# -# -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest -# direction. -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\Phi` fast direction. -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\varphi_2` slow -# direction. -# -# -# -# -# Number of local maxima evaluated in the component analysis. -# -# -# -# -# Number of sampled positions in orientation space. -# -# -# -# -# Base class to store an orientation distribution function (ODF). -# -# An orientation distribution function is a probability distribution that details how -# much volume of material has a specific orientation. An ODF is computed from -# pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. -# -# -# -# Details about the algorithm used for computing the ODF. -# -# -# -# Point group of the crystal structure of the phase for which the here documented phase- -# dependent ODF was computed.(following the notation of the International Table of Crystallography). -# -# -# -# -# Point group assumed for additionally considered sample symmetries -# following the notation of the International Table of Crystallography). -# -# -# -# -# Halfwidth of the kernel. -# -# -# -# -# Name of the kernel. -# -# -# -# -# Resolution of the kernel. -# -# -# -# -# -# -# Group to store descriptors and summary statistics for extrema of the ODF. -# -# -# -# Minima or maxima, if extrema is set to minima values for location and volume_fraction -# are sorted in increasing order. If extrema is set to maxima values for location and -# volume_fraction are sorted in decreasing order. Therefore, the global extremum is -# always the first entry in location and volume_fraction. -# -# -# -# -# -# -# -# -# Number of local extrema evaluated -# -# -# -# -# -# Disorientation threshold within which intensity of the ODF -# is integrated for the component analysis. -# -# -# -# -# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most -# maxima in decreasing order of the intensity maximum. -# -# -# -# -# -# -# -# -# Integrated ODF intensity within a theta angular region of the orientation space (SO3) -# about each location (obeying symmetries) as specified for each location. -# -# -# -# -# -# -# -# -# The ODF intensity values (weights) as sampled with a software. -# -# -# -# Sampling resolution -# -# -# -# -# Bunge-Euler (i.e. ZXZ convention) locations of each position -# in orientation space for which a weight was sampled. -# -# -# -# -# -# -# -# -# Weight at each sampled position following the order in euler. -# -# -# -# -# -# -# -# -# Visualization of the ODF intensity as discretized orthogonal sections through -# orientation space parameterized using Bunge-Euler angles. -# -# This is one example of typical default plots used in the texture community in materials engineering. -# -# Mind that the orientation space is a distorted space when it using an Euler angle parameterization. -# Therefore, equivalent orientations show intensity contributions in eventually multiple locations. -# -# -# -# -# ODF intensity at probed locations relative to the intensity of the null model of -# a random texture. -# -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\varphi_1` direction. -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\Phi` direction. -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\varphi_2` direction. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index a31ed679c0..914ad9bd88 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -11,7 +11,7 @@ symbols: Number of pixel per pole figure in the fast direction. type: group NXmicrostructure_pf(NXprocess): - configuration(NXobject): + configuration(NXparameters): doc: | Details about the algorithm that was used to compute the pole figure. crystal_symmetry_point_group(NX_CHAR): @@ -70,120 +70,3 @@ NXmicrostructure_pf(NXprocess): dim: (n_x,) # \@long_name(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 818e0c5d7f28f02fcf8859aa7ec82dcb88acccc968e404319dfd6b7602e7f66b -# -# -# -# -# -# -# -# Number of pixel per pole figure in the slow direction. -# -# -# -# -# Number of pixel per pole figure in the fast direction. -# -# -# -# -# Base class to store a pole figure (PF) computation. -# -# A pole figure is the X-ray diffraction intensity for specific integrated -# peaks for a hemispherical illumination of a real or virtual specimen. -# -# -# -# Details about the algorithm that was used to compute the pole figure. -# -# -# -# Point group of the crystal structure of the phase for which the pole figure -# was computed (according to International Table of Crystallography). -# -# -# -# -# Point group of assumed sample symmetries (according to International Table of -# Crystallography). -# -# -# -# -# -# Halfwidth of the kernel. -# -# -# -# -# Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. -# -# -# -# -# Resolution of the kernel. -# -# -# -# -# -# Pole figure. -# -# -# -# -# Pole figure intensity. -# -# -# -# -# -# -# -# -# Pixel center along y direction in the equatorial plane of -# a stereographic projection of the unit sphere. -# -# -# -# -# -# -# -# -# Pixel center along x direction in the equatorial plane of -# a stereographic projection of the unit sphere. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index aeb34c4b94..e1e3411515 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -74,7 +74,7 @@ NXmicrostructure_score_config(NXobject): Name of the program whereby this config file was created. program(NX_CHAR): \@version(NX_CHAR): - environment(NXobject): + environment(NXcollection): exists: recommended doc: | Programs and libraries representing the computational environment @@ -104,7 +104,7 @@ NXmicrostructure_score_config(NXobject): unit: NX_TEMPERATURE doc: | Melting temperature - deformation(NXobject): + deformation(NXparameters): doc: | Details about the geometry and properties of the polycrystal that represents the starting configuration (typically a deformed microstructure) for the simulation. @@ -131,7 +131,7 @@ NXmicrostructure_score_config(NXobject): unit: NX_LENGTH doc: | Average spherical diameter when model is poisson_voronoi. - ensemble(NXobject): + ensemble(NXparameters): exists: optional doc: | Settings for instantiating properties of deformed grains when model is cuboidal @@ -182,7 +182,7 @@ NXmicrostructure_score_config(NXobject): algorithm(NX_CHAR): enumeration: [sha256] checksum(NX_CHAR): - nucleation(NXobject): + nucleation(NXparameters): doc: | Phenomenological model according to which recrystallization nuclei are placed into the domain whose growth is studied with the simulation. @@ -206,7 +206,7 @@ NXmicrostructure_score_config(NXobject): * random, picking randomly on the SO3 * damask, picking based on information provided in deformation/damask enumeration: [ensemble, random, damask] - ensemble(NXobject): + ensemble(NXparameters): # required unless custom nucleation model doc: | @@ -227,7 +227,7 @@ NXmicrostructure_score_config(NXobject): dimensions: rank: 1 dim: (n_rx_ori,) - grain_boundary_mobility(NXobject): + grain_boundary_mobility(NXparameters): doc: | Model for the assumed mobility of grain boundaries with different disorientation implemented as parameterized Turnbull's model for thermally-activated @@ -242,7 +242,7 @@ NXmicrostructure_score_config(NXobject): # TODO: add equation for the Sebald-Gottstein model the following equation # TODO: add equation for the Rollett-Holm model the following equation enumeration: [sebald_gottstein, rollett_holm] - sebald_gottstein(NXobject): + sebald_gottstein(NXparameters): exists: optional doc: | Parameter of the Sebald-Gottstein migration model. @@ -283,7 +283,7 @@ NXmicrostructure_score_config(NXobject): Migration activation enthalpy for high-angle grain boundaries which in bicrystal or other tailored experiments showed a particular high mobility. - rollett_holm(NXobject): + rollett_holm(NXparameters): doc: | Parameter of the Rollett-Holm migration model. @@ -308,14 +308,14 @@ NXmicrostructure_score_config(NXobject): unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_3`. Typically 9. - stored_energy_recovery(NXobject): + stored_energy_recovery(NXparameters): doc: | Time-dependent reduction of the stored energy to account for recovery effects. model(NX_CHAR): doc: | Which type of recovery model. enumeration: [none] - dispersoid_drag(NXobject): + dispersoid_drag(NXparameters): doc: | Reduction of the grain boundary migration speed due to the presence of dispersoids through which the total grain boundary area of the recrystallization front can be reduced @@ -324,7 +324,7 @@ NXmicrostructure_score_config(NXobject): doc: | Which type of drag model. enumeration: [none, zener_smith] - zener_smith(NXobject): + zener_smith(NXparameters): # required when model is zener_smith doc: | @@ -367,7 +367,7 @@ NXmicrostructure_score_config(NXobject): rank: 1 dim: (n_drag,) \@long_name(NX_CHAR): - component_analysis(NXobject): + component_analysis(NXparameters): name(NX_CHAR): doc: | Given name of a texture component. @@ -446,7 +446,7 @@ NXmicrostructure_score_config(NXobject): is discretized via equisized cubic voxels. # dim: (d,) - numerics(NXobject): + numerics(NXparameters): doc: | Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -488,7 +488,7 @@ NXmicrostructure_score_config(NXobject): dimensions: rank: 1 dim: (n_snapshot,) - cell_cache(NXobject): + cell_cache(NXparameters): doc: | Parameter which control the memory management of cells in the recrystallization front. @@ -519,7 +519,7 @@ NXmicrostructure_score_config(NXobject): dimensions: rank: 1 dim: (n_defrag,) - solitary_unit(NXobject): + solitary_unit(NXparameters): apply(NX_BOOLEAN): doc: | Perform a statistical analyses of the results as it was proposed @@ -534,750 +534,3 @@ NXmicrostructure_score_config(NXobject): 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. - - # domain_id(NX_UINT): - # doc: | - # List of identifier for those CAs domains which should be sampled. - # Identifier start from 1. - # unit: NX_UNITLESS - # dim: (n_su,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c30a6a2ec88459a497c72482d0641780ecf302b27d54a81ac120a52ac739b3a0 -# -# -# -# -# -# -# -# Number of Bunge-Euler angle triplets for deformed grains. -# -# -# -# -# Number of Bunge-Euler angle triplets for recrystallization nuclei. -# -# -# -# -# Number of texture components to analyze. -# -# -# -# -# Number of support points for the linearized drag profile. -# -# -# -# -# Number of support points for the desired time-temperature profile. -# -# -# -# -# Number of entries when to defragment i.e. garbage collect the memory holding -# state information for recrystallized cells. -# -# -# -# -# Number of entries when to collect snapshots of the evolving microstructure. -# -# -# -# -# Number of solitary unit domains to export. -# -# -# -# -# Dimensionality of the simulation. -# -# -# -# -# Application definition to configure a simulation with the SCORE model. -# -# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ -# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ -# -# -# -# -# -# -# -# -# -# -# An alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the configuration file was created. -# -# -# -# -# -# -# -# -# Dimensionality of the simulation. -# -# -# -# -# -# -# -# A qualifier whether the sample is a real one or a virtual one. -# -# -# -# -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from other sources. -# -# -# -# -# -# Name of the program whereby this config file was created. -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# (Mechanical) properties of the material which scale the -# amount of stored (elastic) energy in the system and -# thus mainly affect recrystallization kinetics. -# -# -# -# Reference shear modulus at zero Kelvin. -# -# -# -# -# Magnitude of the Burgers vector at zero Kelvin. -# -# -# -# -# -# Melting temperature -# -# -# -# -# -# Details about the geometry and properties of the polycrystal that represents the -# starting configuration (typically a deformed microstructure) for the simulation. -# -# -# -# Which model should be used to generate a starting microstructure. -# -# * cuboidal, a regular array of equally shaped cuboidal grains -# * poisson_voronoi, a discretized poisson voronoi -# * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map -# * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# Extent of each deformed grain in voxel along the -# x, y, and z direction when model is cuboidal. -# -# -# -# -# -# -# -# Average spherical diameter when model is poisson_voronoi. -# -# -# -# -# Settings for instantiating properties of deformed grains when model is cuboidal -# or poisson. -# -# -# -# Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) -# out of which the orientations of deformed grains are sampled. -# -# -# -# -# -# -# -# -# Set of stored elastic energy quantified as a dislocation density which is assigned -# to deformed grains with orientations from bunge_euler with index queries matching -# for the bunge_euler and stored_energy fields. -# -# -# -# -# -# -# -# -# Settings for instantiating properties of deformed grains from an -# EBSD orientation map when model is cuboidal or poisson. -# -# -# -# -# -# -# -# -# -# -# Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels -# or cube-shaped voxels respectively. -# -# -# -# -# -# -# -# -# Settings for instantiating properties of deformed grains and nuclei when model -# is damask. -# -# -# -# Name of the DREAM.3D HDF5 file that was instantiated from the -# a previously performed DAMASK simulation. -# -# -# -# -# -# -# -# -# -# -# -# -# Phenomenological model according to which recrystallization nuclei -# are placed into the domain whose growth is studied with the simulation. -# -# -# -# According to which model will the nuclei become distributed spatially: -# -# * csr, complete spatial randomness -# * custom, implementation-specific -# * gb, nuclei placed at grain boundaries -# -# -# -# -# -# -# -# -# -# According to which model will the nuclei start to grow. -# -# -# -# -# -# -# -# According to which model will the nuclei get their orientation assigned: -# -# * ensemble, picking randomly one from ensemble/bunge_euler -# * random, picking randomly on the SO3 -# * damask, picking based on information provided in deformation/damask -# -# -# -# -# -# -# -# -# -# -# -# Settings for instantiating properties of nuclei for recrystallizing grains. -# -# -# -# Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) -# out of which the orientations of nuclei/recrystallized grains are sampled. -# -# -# -# -# -# -# -# -# Incubation time which is assigned to deformed grains with orientations from bunge_euler -# with index queries matching for the bunge_euler and stored_energy fields. -# -# -# -# -# -# -# -# -# -# Model for the assumed mobility of grain boundaries with different disorientation -# implemented as parameterized Turnbull's model for thermally-activated -# grain boundary migration. -# -# -# -# Which type of fundamental model for the grain boundary mobility. -# -# Grain boundaries with disorientation angle smaller than 15 degree are considered -# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. -# -# -# -# -# -# -# -# -# -# Parameter of the Sebald-Gottstein migration model. -# -# -# -# -# Pre-exponential factor for low-angle grain boundaries. -# -# -# -# -# Migration activation enthalpy for low-angle grain boundaries. -# -# -# -# -# Pre-exponential factor for high-angle grain boundaries. -# -# -# -# -# Migration activation enthalpy for high-angle grain boundaries. -# -# -# -# -# Pre-exponential factor for high-angle grain boundaries which in -# bicrystal or other tailored experiments showed a particular high -# mobility. -# -# -# -# -# Migration activation enthalpy for high-angle grain boundaries which in -# bicrystal or other tailored experiments showed a particular high -# mobility. -# -# -# -# -# -# Parameter of the Rollett-Holm migration model. -# -# -# -# -# Pre-exponential factor for the fastest grain boundary in the system. -# -# -# -# -# Migration activation enthalpy for the fastest grain boundary in the system. -# -# -# -# -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not 1. -# -# -# -# -# Mobility scaling factor :math:`c_2`. Typically 5. -# -# -# -# -# Mobility scaling factor :math:`c_3`. Typically 9. -# -# -# -# -# -# -# Time-dependent reduction of the stored energy to account for recovery effects. -# -# -# -# Which type of recovery model. -# -# -# -# -# -# -# -# -# Reduction of the grain boundary migration speed due to the presence of dispersoids -# through which the total grain boundary area of the recrystallization front can be reduced -# while the boundary is arrested at the dispersoids. -# -# -# -# Which type of drag model. -# -# -# -# -# -# -# -# -# -# Parameter of the Zener-Smith drag model when model is zener_smith. -# -# -# -# Configuration-dependent constant which factorizes the drag pressure. -# -# -# -# -# Average surface energy of the grain-boundary-dispersoid-surface configuration -# which factorizes the drag pressure. -# -# -# -# -# -# Assumed dispersoid mean radius-time profile -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# Given name of a texture component. -# -# -# -# -# -# -# -# Bunge-Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the -# of texture components in sequence of the name field. -# -# -# -# -# -# -# -# -# Integration radius that constraints the theta angular region of the orientation space (SO3) -# about each central location (obeying symmetries) as specified by bunge_euler indexed in -# the same sequence as the bunge_euler and name fields. -# -# -# -# -# -# -# -# -# Desired 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. -# -# -# -# -# -# -# -# -# -# Relevant data to instantiate a starting configuration that is typically -# a microstructure in deformed conditions where (elastic) energy is stored -# in the form of crystal defects (mostly dislocations). The SCORE model -# does not resolve individual dislocations but works with one -# homogenized mean-field density per grain. For simulations that are -# instantiated from EBSD datasets or crystal plasticity simulations -# individual values are available for each voxel that may be used as is -# for each voxel or may need a pre-processing of the data to coarse-grain -# material point-specific values to values averaged per deformed grain. -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Edge length of the material point that in SCORE -# is discretized via equisized cubic voxels. -# -# -# -# -# -# -# -# Criteria which enable to stop the simulation in a controlled manner. -# Whichever criterion is fulfilled first stops the simulation. -# Furthermore, numerical configuration required to achieve -# a stable numerical integration. -# -# -# -# Maximum recrystallized volume fraction. -# -# -# -# -# Maximum simulated physical time. -# -# -# -# -# Maximum number of iteration steps. -# -# -# -# -# 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. -# -# -# -# -# List of target values at which recrystallized volume fractions the state -# of the CA is evaluated and stored. The code documents summary statistics -# like recrystallized volume fraction for each iteration and the volume of each -# grain. Furthermore, snapshots of the microstructure are stored. -# These can take much disk space though because SCORE is able to evolve CA -# with up to :math:`1600^3` cells. Snapshot data document the current microstructure -# including the assignment of grains and cells surplus the state of the -# recrystallization front. -# -# Despite these front data make up for approximately one order of magnitude -# less cells than represented in the domain, more numerical data have to be -# collected for each cell in the front than just a grain identifier. -# -# -# -# -# -# -# -# Parameter which control the memory management -# of cells in the recrystallization front. -# -# -# -# Fraction of the total number of cells in the CA which -# should initially be allocated for offering storage for -# cells making up the recrystallization front. -# -# -# -# -# By how much more times should the already allocated memory -# be 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 or not. -# -# -# -# -# Target values at which recrystallized volume fraction the cache -# for cells in the recrystallization front will be defragmented -# on-the-fly. Defragmentation packs active cells closer into -# main memory to reduce cache misses in subsequent evaluations -# of the recrystallization front. -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 45d92a280e..de91877535 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -72,7 +72,7 @@ NXmicrostructure_score_results(NXobject): Name of the program with which the simulation was performed. program(NX_CHAR): \@version: - environment(NXobject): + environment(NXcollection): # NXcs_environment ? exists: optional doc: | Programs and libraries representing the computational environment @@ -149,7 +149,7 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (6,) - SPATIOTEMPORAL(NXobject): + SPATIOTEMPORAL(NXprocess): nameType: any exists: ['min', '1', 'max', 'unbounded'] doc: | @@ -308,7 +308,7 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 3 dim: (n_x, n_y, n_z) - crystals(NXobject): + crystals(NXmicrostructure_feature): representation(NX_CHAR): exists: recommended number_of_crystals(NX_UINT): @@ -368,7 +368,7 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (n_grains,) - recrystallization_front(NXobject): + recrystallization_front(NXmicrostructure_feature): # NXcollection ? exists: recommended doc: | Details about those cells which in this time step represent the discrete @@ -433,571 +433,3 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (n_front,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a320be56a25af3f446f52036613675dd547906e0f92efd90c0845bff135ad72b -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# The total number of summary statistic log entries -# -# -# -# -# Number of boundaries of the bounding box or primitive about the computational -# 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 automata model. -# -# The SCORE cellular automata model for primary recrystallization is an example -# of a typical materials engineering application 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 nuclei during -# static recrystallization. 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>`_ -# -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Configuration file with the parameterization of the -# SCORE model that was used for this simulation. -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the simulation was started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the simulation ended. -# -# -# -# -# -# -# Name of the program with which the simulation was performed. -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# The boundary conditions for each boundary: -# -# * 0 - undefined -# * 1 - open -# * 2 - periodic -# * 3 - mirror -# * 4 - von Neumann -# * 5 - Dirichlet -# -# -# -# -# -# -# -# -# Name of the boundaries. Left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. -# -# -# -# -# -# -# -# -# -# Documentation of the spatiotemporal evolution for each CA domain. -# -# SCORE is a hybrid parallelized code that can evolve multiple replicas -# in parallel. The set of replicas is distributed across MPI processes. -# Each such replica is then evolved via OpenMP multi-threading. -# -# Instances should use spatiotemporal as a name prefix. -# -# -# -# -# Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening for practical and performance reasons -# during the simulation. Place used for storing descriptors from continuum mechanics -# and thermodynamics at the scale of the entire ROI. -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# -# -# -# -# -# -# -# Evolution of the physical time not to be confused with wall-clock time or -# profiling data. -# -# -# -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# -# -# -# Evolution of the simulated temperature over time. -# -# -# -# -# -# -# -# Recrystallized volume fraction. -# -# -# -# -# -# -# -# -# -# Which type of stress. -# -# -# -# -# -# -# -# Applied external stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of strain. -# -# -# -# -# Applied external strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of deformation gradient. -# -# -# -# -# -# -# -# Applied deformation gradient tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use microstructure as a name prefix. -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# Simulated temperature for this snapshot. -# -# -# -# -# Current recrystallized volume fraction (taking fractional infections into -# account). -# -# -# -# -# Target value for which a snapshot was requested for the recrystallized volume -# fraction. -# -# -# -# -# -# -# Index for each crystal whereby its metadata can be retrieved. -# -# -# -# -# -# -# -# -# -# Identifier of the OpenMP thread that processed this part of the grid. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Volume of each grain accounting also for partially transformed cells. -# -# -# -# -# -# -# -# -# Bunge-Euler angle triplets for each grain. -# -# -# -# -# -# -# -# -# Current value for the dislocation density as a measure of the remaining -# stored energy in assumed crystal defects inside each grain. -# -# -# -# -# -# -# -# Is the grain deformed. -# -# -# -# -# -# -# -# Is the grain recrystallized. -# -# -# -# -# -# -# -# -# Details about those cells which in this time step represent the discrete -# 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 that is modelled sweeping cells that -# make the discrete recrystallization front. -# -# -# -# -# -# -# -# The x, y, z 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. -# -# -# -# -# -# -# -# Identifier of the OpenMP thread processing each cell in the recrystallization -# front. -# -# -# -# -# -# -# -# Hint about the direction from which the cell was infected. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 0000000000..50f93c6ba2 --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + Base class to report on a region-of-interest of material analyzed. + + Do not confuse this base class with :ref:`NXregion`. +type: group +NXroi(NXobject): + (NXem_img): + (NXem_ebsd): + (NXem_eds): + (NXem_eels): From 3a380cb5efe765deccd15bc15c78581792a01740 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 7 May 2025 22:22:32 +0200 Subject: [PATCH 11/57] Further reverting for NXobject for APM-part of the proposal --- .../nyaml/NXapm_compositionspace_config.yaml | 313 +++--------------- 1 file changed, 50 insertions(+), 263 deletions(-) diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index df7c6fc42e..1740a3db22 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -9,68 +9,65 @@ doc: | CompositionSpace tool by using the NeXus data model and semantics. type: group NXapm_compositionspace_config(NXobject): - - # by default for application definitions the value of the exists keyword is required unless it is explicitly specified differently (NXentry): exists: ['min', '1', 'max', '1'] definition(NX_CHAR): \@version(NX_CHAR): exists: optional enumeration: [NXapm_compositionspace_config] - config(NXobject): - identifier_analysis(NX_UINT): + identifier_analysis(NX_UINT): + exists: recommended + reconstruction(NXnote): + doc: | + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + type(NX_CHAR): + exists: optional + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): exists: recommended - reconstruction(NXnote): + position(NX_CHAR): doc: | - Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. - type(NX_CHAR): - exists: optional - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - position(NX_CHAR): - doc: | - Name of the node which resolves the reconstructed - ion position values to use for this analysis. - mass_to_charge(NX_CHAR): - exists: optional - doc: | - Name of the node which resolves the mass-to-charge-state ratio - values for each reconstructed ion to use for this analysis. - ranging(NXnote): + Name of the node which resolves the reconstructed + ion position values to use for this analysis. + mass_to_charge(NX_CHAR): + exists: optional doc: | - Specification of the ranging definitions used for this analysis. - - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - type(NX_CHAR): - exists: optional - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - ranging_definitions(NX_CHAR): - doc: | - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. - voxelization(NXprocess): + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. + ranging(NXnote): + doc: | + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + type(NX_CHAR): + exists: optional + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + ranging_definitions(NX_CHAR): doc: | - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Edge length of cubic voxels building the 3D grid that is used for discretizing - the point cloud. + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. + voxelization(NXprocess): + doc: | + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. autophase(NXprocess): doc: | Optional step during which the subsequent segmentation step is prepared with the aim to eventually @@ -125,7 +122,7 @@ NXapm_compositionspace_config(NXobject): doc: | Step during which the chemically segmented voxel sets are analyzed for their spatial organization. - dbscan(NXobject): + dbscan(NXparameters): doc: | Configuration for the DBScan algorithm that is used in the clustering step. eps(NX_FLOAT): @@ -151,213 +148,3 @@ NXapm_compositionspace_config(NXobject): TODO # units: NX_ANY - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fc965247557b83b2c74919c9b6b0a5292618ea92448b07eb58f5999a228e901b -# -# -# -# -# -# Application definition for a configuration of the CompositionSpace tool used in atom probe. -# -# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ -# -# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure -# use case IUC09 that explores how to improve the organization and results storage of the -# CompositionSpace tool by using the NeXus data model and semantics. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of the tomographic reconstruction used for this analysis. -# Typically, reconstructions in the field of atom probe tomography are communicated via -# files which store at least reconstructed ion positions and mass-to-charge-state-ratio -# values. Container files like HDF5 though can store multiple reconstructions. -# Therefore, the position and mass_to_charge concepts point to specific instances -# to use for this analysis. -# -# -# -# -# -# -# -# Name of the node which resolves the reconstructed -# ion position values to use for this analysis. -# -# -# -# -# Name of the node which resolves the mass-to-charge-state ratio -# values for each reconstructed ion to use for this analysis. -# -# -# -# -# -# Specification of the ranging definitions used for this analysis. -# -# Indices start from 1. The value 0 is reserved for the null model of unranged positions whose -# iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. -# -# -# -# -# -# -# -# Name of the (parent) node directly below which the ranging definitions for -# (molecular) ions are stored. -# -# -# -# -# -# Step during which the point cloud is discretized to compute element-specific composition fields. -# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that -# was ranged for each ion. -# -# -# -# Edge length of cubic voxels building the 3D grid that is used for discretizing -# the point cloud. -# -# -# -# -# -# Optional step during which the subsequent segmentation step is prepared with the aim to eventually -# reduce the dimensionality of the chemical space in which the machine learning model works. -# -# In this step a supervised reduction of the dimensionality of the chemical space is quantified using -# the (Gini) feature importance of each element to suggest which columns of the composition matrix -# should be taken for the subsequent segmentation step. -# -# -# -# Was the automated phase assignment used? -# -# -# -# -# Estimated guess for which a Gaussian mixture model is evaluated to preprocess a result that -# is subsequently post-processed with a random_forest_classifier to lower the number of -# dimensions in the chemical space to the subset of trunc_species many elements with the -# highest feature importance. -# -# -# -# -# The number of elements to use for reducing the dimensionality. -# -# -# -# -# Configuration for the random forest classification model. -# -# -# -# -# -# Step during which the voxel set is segmented into voxel sets with different -# chemical composition. -# -# -# -# A principal component analysis of the chemical space to guide a decision into how many sets of voxels -# with different chemical composition the machine learning algorithm suggests to split the voxel set. -# -# -# -# -# The decision is guided through the evaluation of the information criterion -# minimization. -# -# -# -# The maximum number of chemical classes to probe with the Gaussian mixture model -# with which the voxel set is segmented into a mixture of voxels with that many different -# chemical compositions. -# -# -# -# -# Configuration for the Gaussian mixture model that is used in the segmentation -# step. -# -# -# -# -# -# -# Step during which the chemically segmented voxel sets are analyzed for their -# spatial organization. -# -# -# -# Configuration for the DBScan algorithm that is used in the clustering step. -# -# -# -# The maximum distance between voxel pairs in a neighborhood to be considered -# connected. -# -# -# -# -# The number of voxels in a neighborhood for a -# voxel to be considered as a core point. -# -# -# -# -# -# -# TODO -# -# -# -# TODO -# -# -# -# -# -# TODO -# -# -# -# -# -# -# From 9a1f44cc07617b2646ac149fc4431333614f9d5e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 11:58:08 +0200 Subject: [PATCH 12/57] Further removing of NXobject and indenting NXevent_data in NXem. After thinking further about grouping NXevent_data instance or not I thought it could also be a valid argument that as why should the standard force people to not have thousands of groups ending up at the same level of the hierarchy. Clearly, there is nothing which prevents sb from doing this for the example of HDF5 but performance-wise this is problematic, there are multiple examples even in commercial microscope software solutions where indeed HDF5 files with thousands and more groups at the same level are stored using HDF5, while there is overhead involved in this and searching by humans might be ineffective it is still a valid HDF5 file according to the HDF5 data model. Also NeXus with allowing an (NXentry) de facto allows to make an instance where thousands of e.g. entry1, entry2, ... are stored in the same HDF5 file also here no attempt has been made to build another group to just suggest strongly that people avoid this practice. Therefore, I removed one layer of indentation within NXem_measurement so that in an instance one now can have instrument, event1, event2, .. It is a design issue with NeXus that when we accept and wish that one cannot use NXobject as a plain structuring element but at the same time does not wish ones content to become at the schema level already non verified like when using an NXcollection there is no practice to group content other than making a new base class such for the sake of it holding the grouping. --- contributed_definitions/NXapm.nxdl.xml | 148 +- .../NXapm_compositionspace_config.nxdl.xml | 109 +- ...em.nxdl.xml => NXapm_measurement.nxdl.xml} | 8 +- .../NXapm_simulation.nxdl.xml | 33 + contributed_definitions/NXem.nxdl.xml | 1215 +++++++------ .../NXem_measurement.nxdl.xml | 4 +- .../NXem_simulation.nxdl.xml | 5 +- .../NXevent_data_apm.nxdl.xml | 14 +- .../NXevent_data_em.nxdl.xml | 18 +- contributed_definitions/NXroi.nxdl.xml | 8 +- contributed_definitions/nyaml/NXapm.yaml | 1513 +---------------- .../nyaml/NXapm_measurement.yaml | 7 + .../nyaml/NXapm_simulation.yaml | 9 + contributed_definitions/nyaml/NXem.yaml | 1158 +++++++------ .../nyaml/NXem_measurement.yaml | 4 +- .../nyaml/NXem_simulation.yaml | 4 +- .../nyaml/NXevent_data_apm.yaml | 14 +- .../nyaml/NXevent_data_em.yaml | 18 +- contributed_definitions/nyaml/NXevent_em.yaml | 9 - .../nyaml/NXinteraction_volume_em.yaml | 2 +- contributed_definitions/nyaml/NXroi.yaml | 8 +- 21 files changed, 1480 insertions(+), 2828 deletions(-) rename contributed_definitions/{NXevent_em.nxdl.xml => NXapm_measurement.nxdl.xml} (78%) create mode 100644 contributed_definitions/NXapm_simulation.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_measurement.yaml create mode 100644 contributed_definitions/nyaml/NXapm_simulation.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_em.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 57468a4d89..203391e187 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -3,7 +3,7 @@ + @@ -417,7 +417,7 @@ the application definition here is nothing else then the documentation of this f - + The conventions used when reporting crystal orientations. We follow the best practices of the Material Science community @@ -542,7 +542,7 @@ the application definition here is nothing else then the documentation of this f - + Base class for collecting a session with a real atom probe or field-ion microscope. @@ -689,113 +689,85 @@ the application definition here is nothing else then the documentation of this f - - + + - Group to hold instances of :ref:`NXevent_data_apm`. - - Which temporal granularity is adequate depends on the situation and research - question. Using a model which enables a collection of events offers the most - flexible way to cater for both atom probe experiments or simulation. - - To monitor the course of an ion extraction experiment (or simulation) - it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser - and respective pulsing event identifier. - - As set and measured quantities typically change over time and we do not - yet know during the measurement which of the events have associated - (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the evaporation_id but as a - function of the (pulsing) identifier_event. + Instances should use event as a name prefix. - - - - Instances should use event as a name prefix. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - + + + + - - - + + + + + + + + + - + Simulation of ion extraction from matter via laser and/or voltage pulsing. - + A region-of-interest analyzed either during or after the session for which specific processed data of the measured or simulated data are available. diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index 91912d6c4a..bada496613 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -3,7 +3,7 @@ @@ -39,65 +38,63 @@ - - - + + + + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + + + - Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. + Name of the node which resolves the reconstructed + ion position values to use for this analysis. - - - - - - - Name of the node which resolves the reconstructed - ion position values to use for this analysis. - - - - - Name of the node which resolves the mass-to-charge-state ratio - values for each reconstructed ion to use for this analysis. - - - - + + - Specification of the ranging definitions used for this analysis. - - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. - - - - - - - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. - - - - + + + + + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + + + + + + - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. - - - Edge length of cubic voxels building the 3D grid that is used for discretizing - the point cloud. - - - + + + + + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + + + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. + + Optional step during which the subsequent segmentation step is prepared with the aim to eventually @@ -167,7 +164,7 @@ Step during which the chemically segmented voxel sets are analyzed for their spatial organization. - + Configuration for the DBScan algorithm that is used in the clustering step. diff --git a/contributed_definitions/NXevent_em.nxdl.xml b/contributed_definitions/NXapm_measurement.nxdl.xml similarity index 78% rename from contributed_definitions/NXevent_em.nxdl.xml rename to contributed_definitions/NXapm_measurement.nxdl.xml index aae803dc61..37a579e7de 100644 --- a/contributed_definitions/NXevent_em.nxdl.xml +++ b/contributed_definitions/NXapm_measurement.nxdl.xml @@ -21,12 +21,10 @@ # # For further information, see http://www.nexusformat.org --> - + - Base class for grouping instances of :ref:`NXevent_data_em`. - - This group should be used to bundle all event-related (meta)data - and measured data including images and spectra. + Base class for documenting a measurement with an electron microscope. + diff --git a/contributed_definitions/NXapm_simulation.nxdl.xml b/contributed_definitions/NXapm_simulation.nxdl.xml new file mode 100644 index 0000000000..45afabf52c --- /dev/null +++ b/contributed_definitions/NXapm_simulation.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + Base class for documenting a simulation of removing ions from a specimen and + characterizing them. + + + + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 3fcca09f78..4d4f1e9120 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -187,7 +187,7 @@ but for practical purposes currently is interpretable only by human to provide t - + A physical entity which contains material intended to be investigated. Sample and specimen are treated as de facto synonyms. @@ -889,617 +889,574 @@ which components that microscope was built from--> - - - - To avoid that static instrument-related metadata need to be stored - repetitively, the NXem application definitions splits the storage of the - dynamic (meta)data that typically change for each image and spectrum - from the static one. - - - - - - - - - Instances should use image as a name prefix. - Each NXimage instance must use only one image or stack instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + Instances should use image as a name prefix. + Each NXimage instance must use only one image or stack instance. + + + + + + + + + - - - Instances should use spectrum as a name prefix. - Each NXspectrum instance must use only one spectrum or stack instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Instances should use spectrum as a name prefix. + Each NXspectrum instance must use only one spectrum or stack instance. + + + + + + + + - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - + + + Instances should use lens as a name prefix. + + - - - - - - - - - - - - - - - - - - - + + + Instances should use aperture as a name prefix. + + + + Descriptor for the aperture setting 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 users. + - - - - - - - - - - - - - - - - - - - - - - - + + + + Instances should use monochromator as a name prefix. + + + + - - - - - - - - - - - - - Instances should use lens as a name prefix. - - - - - - Instances should use aperture as a name prefix. - - - - Descriptor for the aperture setting 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 users. - - - - - + + + + + - Instances should use monochromator as a name prefix. + Instances should use tableau as a name prefix. - - - - - - - - - - - Instances should use tableau as a name prefix. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + - - - - - - - - - Instances should use lens as a name prefix. - - - - - - Instances should use aperture as a name prefix. - - - - Descriptor for the aperture setting 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 users. - - - - - - Instances should use monochromator as a name prefix. - - - - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + + Instances should use sensor as a name prefix. + + + + + Instances should use actuator as a name prefix. + + + + + Instances should use beam as a name prefix. + + + + + Instances should use deflector as a name prefix. + - + + + + + + + + + + Instances should use lens as a name prefix. + + + + - Instances should use detector as a name prefix. + Instances should use aperture as a name prefix. - + - Operation mode of the detector as displayed by the control software. + Descriptor for the aperture setting 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 users. - - - + + + Instances should use monochromator as a name prefix. + + @@ -1511,29 +1468,63 @@ basically optional use of NXaberration therein at least some value required--> Instances should use actuator as a name prefix. - - - - - - - - - - - Nominal current of the heater. - - - - - Nominal voltage of the heater. - - - - + + + Instances should use beam as a name prefix. + + + + + Instances should use deflector as a name prefix. + + + + + + Instances should use detector as a name prefix. + + + + Operation mode of the detector as displayed by the control software. + + + + + + + + + + Instances should use sensor as a name prefix. + + + + + Instances should use actuator as a name prefix. + + + + + + + + + + + + + Nominal current of the heater. + + + + + Nominal voltage of the heater. + + + - + diff --git a/contributed_definitions/NXem_measurement.nxdl.xml b/contributed_definitions/NXem_measurement.nxdl.xml index f6213518e8..37a579e7de 100644 --- a/contributed_definitions/NXem_measurement.nxdl.xml +++ b/contributed_definitions/NXem_measurement.nxdl.xml @@ -23,6 +23,8 @@ --> - Base class for ################ + Base class for documenting a measurement with an electron microscope. + + diff --git a/contributed_definitions/NXem_simulation.nxdl.xml b/contributed_definitions/NXem_simulation.nxdl.xml index d6a22901a2..58b3ec885c 100644 --- a/contributed_definitions/NXem_simulation.nxdl.xml +++ b/contributed_definitions/NXem_simulation.nxdl.xml @@ -21,10 +21,9 @@ # # For further information, see http://www.nexusformat.org --> - + - Base class for documenting a set of simulations of electron beam-matter - interaction. + Base class for documenting a simulation of electron beam-matter interaction. diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 39fac4b100..1199b29203 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -37,13 +37,25 @@ Having at least one instance for an instance of NXapm is recommended. - This base class applies the concept of the NXevent_data_em base class to the specific needs + This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs of atom probe research. Against static and dynamic quantities are split to avoid a duplication of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. These pulses are identified via the pulse_id field. The point in time when each was issued is specified via the combination of start_time and delta_time. + Which temporal granularity is adequate depends on the situation and research question. + Using a model which enables a collection of events offers the most flexible way to cater for + both atom probe experiments or simulation. To monitor the course of an ion extraction experiment + (or simulation) it makes sense to track time explicitly via time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event + identifier. + + As set and measured quantities typically change over time and we do not yet know during the + measurement which of the events have associated (molecular) ions that will end up in the + reconstructed volume, we must not document quantities as a function of the evaporation_id but + as a function of the (pulsing) identifier_event. + Conceptually and technically NeXus currently stores tensorial information as arrays of values (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores a set of temperature values but that field when used somewhere is a concept. However, that diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 5f8396228f..75153913a6 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -25,6 +25,18 @@ Base class to store state and (meta)data of events for electron microscopy. + To avoid that static instrument-related metadata need to be stored repetitively + (for each image and spectrum) the NXem application definitions splits the + storage of the (meta)data into those that typically do not change for a session + with the microscope and those which are often different for data that is collected + with the microscope. + + Which temporal granularity is adequate to log events depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + Electron microscopes are dynamic. Scientists often report that microscopes *perform differently* across sessions. That *they* perform differently from one day or another. In some cases, root causes for performance differences @@ -33,12 +45,6 @@ bring the microscope into a state where conditions are considered better or of whatever high enough quality for starting or continuing the measurement. - Which temporal granularity is adequate to log events depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - In all these use cases it is useful to have a mechanism whereby time-dependent data of the instrument state can be stored and documented in an representation that facilitates interoperability. diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index 73af0d7a1d..249a81edda 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -23,10 +23,16 @@ --> - Base class to report on a region-of-interest of material analyzed. + Base class to report on a region-of-interest of material analyzed or simulated. Do not confuse this base class with :ref:`NXregion`. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index e8d4444fed..db35bebec3 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -63,7 +63,6 @@ NXapm(NXobject): run_number(NX_UINT): exists: recommended unit: NX_UNITLESS - # cannot be made required as for simulations you do not have a run number! doc: | The identifier whereby the experiment is referred to in the control software. @@ -358,7 +357,7 @@ NXapm(NXobject): 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. - consistent_rotations(NXobject): + consistent_rotations(NXparameters): exists: recommended doc: | The conventions used when reporting crystal orientations. @@ -447,7 +446,7 @@ NXapm(NXobject): x_direction(NX_CHAR): y_direction(NX_CHAR): z_direction(NX_CHAR): - measurement(NXobject): + measurement(NXapm_measurement): #### exists: optional doc: | Base class for collecting a session with a real atom probe or field-ion microscope. @@ -589,126 +588,86 @@ NXapm(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - # wavelength and pulse_energy as dynamic/volatile quantities stored in event data part comment(NX_CHAR): doc: | Free text field for additional comments. - events(NXobject): - exists: optional - - # the case of allowing to not have event_data but only the above-mentioned instrument - # details can be useful to convey details about an atom probe instrument in general + (NXevent_data_apm): + exists: ['min', '0', 'max', 'unbounded'] + # all these cannot be made required because for LEAP only stored in RHIT/HITS + # but for M-TAP and Oxcart these pieces of information are available. doc: | - Group to hold instances of :ref:`NXevent_data_apm`. - - Which temporal granularity is adequate depends on the situation and research - question. Using a model which enables a collection of events offers the most - flexible way to cater for both atom probe experiments or simulation. - - To monitor the course of an ion extraction experiment (or simulation) - it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser - and respective pulsing event identifier. - - As set and measured quantities typically change over time and we do not - yet know during the measurement which of the events have associated - (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the evaporation_id but as a - function of the (pulsing) identifier_event. - (NXevent_data_apm): - exists: ['min', '0', 'max', 'unbounded'] - - # all these cannot be made required because for LEAP only stored in RHIT/HITS - # but for M-TAP and Oxcart these pieces of information are available. - doc: | - Instances should use event as a name prefix. - start_time(NX_DATE_TIME): + Instances should use event as a name prefix. + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + # delta_time(NX_NUMBER): + # pulse_id_offset(NX_INT): + # pulse_id(NX_INT): + instrument(NXinstrument_apm): + exists: recommended + reflectron(NXcomponent): exists: recommended - end_time(NX_DATE_TIME): + voltage(NX_FLOAT): + # decelerate_electrode(NXlens_em): + local_electrode(NXlens_em): exists: recommended - - # delta_time(NX_NUMBER): - # pulse_id_offset(NX_INT): - # pulse_id(NX_INT): - instrument(NXinstrument_apm): + voltage(NX_FLOAT): + # ion_detector(NXdetector): + pulser(NXcomponent): exists: recommended - reflectron(NXcomponent): - exists: recommended - voltage(NX_FLOAT): - - # decelerate_electrode(NXlens_em): - local_electrode(NXlens_em): - exists: recommended - voltage(NX_FLOAT): - - # ion_detector(NXdetector): - pulser(NXcomponent): - exists: recommended - pulse_mode(NX_CHAR): - pulse_frequency(NX_FLOAT): - - # \@logged_against(NX_CHAR): - pulse_fraction(NX_FLOAT): - - # \@logged_against(NX_CHAR): - pulse_voltage(NX_FLOAT): - exists: optional - dimensions: - rank: 1 - dim: (n,) - - # \@logged_against(NX_CHAR): - pulse_number(NX_UINT): - exists: optional - dimensions: - rank: 1 - dim: (n,) - - # \@logged_against(NX_CHAR): - standing_voltage(NX_FLOAT): - exists: optional + pulse_mode(NX_CHAR): + pulse_frequency(NX_FLOAT): + pulse_fraction(NX_FLOAT): + pulse_voltage(NX_FLOAT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + pulse_number(NX_UINT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + standing_voltage(NX_FLOAT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + (NXsource): + exists: ['min', '0', 'max', '2'] + wavelength(NX_FLOAT): + exists: recommended + unit: NX_WAVELENGTH + power(NX_FLOAT): + unit: NX_POWER + pulse_energy(NX_FLOAT): dimensions: rank: 1 dim: (n,) - - # \@logged_against(NX_CHAR): - (NXsource): - exists: ['min', '0', 'max', '2'] - wavelength(NX_FLOAT): - exists: recommended - unit: NX_WAVELENGTH - power(NX_FLOAT): - unit: NX_POWER - pulse_energy(NX_FLOAT): - dimensions: - rank: 1 - dim: (n,) - - # \@logged_against(NX_CHAR): # laser geometry at the moment has neither a worked out example # nor any feedback from the community despite the work from B. Gault # on laser atom probe was granted a Leibnitz award - stage(NXmanipulator): - temperature_sensor(NXsensor): - measurement(NX_CHAR): - value(NX_FLOAT): - analysis_chamber(NXcomponent): - pressure_sensor(NXsensor): - measurement(NX_CHAR): - value(NX_FLOAT): - control(NXcollection): - exists: recommended - evaporation_control(NX_CHAR): - target_detection_rate(NX_NUMBER): - simulation(NXobject): + stage(NXmanipulator): + temperature_sensor(NXsensor): + measurement(NX_CHAR): + value(NX_FLOAT): + analysis_chamber(NXcomponent): + pressure_sensor(NXsensor): + measurement(NX_CHAR): + value(NX_FLOAT): + control(NXparameters): + exists: recommended + evaporation_control(NX_CHAR): + target_detection_rate(NX_NUMBER): + simulation(NXapm_simulation): exists: optional doc: | Simulation of ion extraction from matter via laser and/or voltage pulsing. - # future possibility to reuse concepts from NXinstrument_apm again without # the need for defining them again - atom_probe(NXobject): + atom_probe(NXroi): exists: recommended doc: | A region-of-interest analyzed either during or after the session for which @@ -1232,1349 +1191,3 @@ NXapm(NXobject): exists: recommended name(NX_CHAR): exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60b2bc45c73a1c8918e6bbd792bd2fc603c0fbfe0f054bb53350b2f4d3f6a3a1 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of hit qualities (hit types) distinguished. -# -# -# -# -# Number of delay-line wires of the detector. -# -# -# -# -# Number of bins used in the mass-to-charge-state-ratio spectrum. -# -# -# -# -# Number of pulses collected in between start_time and end_time resolved by an -# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of -# ions included in the reconstructed volume if the application definition is used -# to store results of an already reconstructed datasets. -# -# -# -# -# Number of pulses returned by the hit finding algorithm. -# Neither necessarily equal to p nor to n. -# -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# from which an instance of a reconstructed volume has been generated. -# These ions get new identifier assigned in the process (the so-called -# evaporation_id). This identifier must not be confused with -# the pulse_id. Typically smaller than both p_out and p_out. -# -# -# -# -# Application definition for atom probe and field ion microscopy experiments. -# -# -# -# -# -# -# -# -# -# -# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) -# which was used to generate this NeXus file instance. -# -# -# -# -# A collection of all programs and libraries which are considered relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# -# -# -# -# -# -# -# -# -# The identifier whereby the experiment is referred to in the control software. -# This is neither the specimen_name nor the experiment_identifier. For -# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the -# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. -# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, -# or the instruments at GPM in Rouen, use the identifier which matches -# best conceptually 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 (provided these -# RHIT or HITS files respectively are stored alongside a data artifact). -# With NXapm the RHIT or HITS can be stored via NXnote in the -# hit_finding algorithm section. -# -# 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. Such interrupted runs -# should be stored as individual :ref:`NXentry` instances in one NeXus file. -# -# -# -# -# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. -# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. -# -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the atom probe session started. If the exact duration of -# the measurement is not relevant start_time only should be used. -# -# Often though it is useful to specify both start_time and end_time to -# capture more detailed bookkeeping 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. For this -# purpose the :ref:`NXevent_data_apm` instance should be used. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the atom probe session ended. -# -# -# -# -# How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime -# -# -# -# -# -# -# -# -# -# -# -# -# -# What type of atom probe experiment is performed? This field is meant to -# inform research data management systems to allow filtering: -# -# * apt are experiments where the analysis_chamber has no imaging gas. -# experiment with LEAP instruments are typically performed such. -# * 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. -# few experiments of this type have been performed as this can be detrimental -# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). -# * other should be used in combination with the user specifying details -# in the experiment_documentation field. -# -# If NXapm is used for storing details about a simulation use other for now. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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 knowledge they have gained about the sample. -# There are cases where the specimen is machined further or exposed to -# external stimuli during the experiment. In this case, these details should -# not be stored under sample but suggestions should be made -# how this application definition can be improved. -# -# 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. For this specific application definitions/schemas can be -# used which are then arranged and documented with a description of the -# workflow so that actionable graphs become instantiatable. -# -# -# -# -# Qualifier whether the sample is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# Given name/alias for the sample. -# -# -# -# -# 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. -# -# In atom probe it is possible that the specimen may contain a few -# crystals only. In this case the grain_diameter is not a reliable -# descriptor. Reporting a grain size may be useful though as it allows -# judging if specific features are expected to be found in the -# detector hit map. -# -# -# -# -# Magnitude of the standard deviation of 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 a documentation of the annealing -# treatment as a function of time is available one should better -# rely on this information and have it stored alongside the NeXus file. -# -# -# -# -# Magnitude of the standard deviation of the heat_treatment_temperature. -# -# -# -# -# Rate of the last quenching step. Knowledge about this value can give -# an idea how the sample was heat treated. However, there are many -# situations where one can imagine that the scalar value for just the -# quenching rate is insufficient. -# -# An example is when the sample was left in the furnace after the -# furnace was switched off. In this case the sample cools down with -# a specific rate of how this furnace cools down in the lab. -# Processes which in practice are often not documented. -# -# This can be problematic though because when the furnace door was left open -# or the ambient temperature in the lab changed, i.e. for a series of -# experiments where one is conducted on a hot summer day and the next -# during winter this can have an effect on the evolution of the microstructure. -# There are many cases where this has been reported to be an QA issue in industry, -# e.g. think about aging aluminum samples left on the factory -# parking lot on a hot summer day. -# -# -# -# -# Magnitude of the 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Qualifier whether the specimen is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# Given name an alias. Better use identifierNAME and identifier_parent instead. -# A single NXentry should be used only for the characterization of a single specimen. -# -# -# -# -# Identifier of the sample from which the specimen was cut or the string -# n/a. The purpose of this field is to support functionalities for -# tracking sample provenance via a research data management system. -# -# -# -# -# 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. Ideally, this -# matches the last timestamp that is mentioned in the digital resource -# pointed to by identifier_parent. -# -# 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. Additional time stamps prior to preparation_date -# should better be placed in resources which describe but which do not -# pollute the description here with prose. Resolving these connected -# pieces of information is considered within the responsibility of the -# research data management system. -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources pointed to by identifier_parent or walk through -# eventually deeply nested groups in data instances. -# -# -# -# -# Discouraged free-text field. -# -# -# -# -# Report if the specimen is polycrystalline, in which case it -# contains a grain or phase boundary, or if the specimen is a -# single crystal. -# -# -# -# -# Report if the specimen is amorphous. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the initial radius of the -# specimen. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the (initial) 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. -# -# -# -# -# -# The conventions used when reporting crystal orientations. -# We follow the best practices of the Material Science community -# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin. -# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parametrizations/representations according -# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# -# A collection of coordinate systems. Several Euclidean -# coordinate systems (CS) are used in the field of atom probe: -# -# * 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. -# -# 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 identifier interval. Typically, the set of -# ion evaporation sequence identifiers 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. -# -# To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. -# -# -# -# -# -# -# -# -# -# -# -# Base class for collecting a session with a real atom probe or field-ion microscope. -# -# Workflows used during experiments or simulations of atom probe and related field-evaporation -# research should be documented in more detail and be better contextualized not only because of -# ongoing developments and the tighter becoming connection between atom probe and other -# methods for material characterization foremost electron microscopy see e.g.: -# -# * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ -# * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ -# * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ -# * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ -# * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ -# -# to mention but a few. -# -# To arrive at a design of base classes and an application definition that can be used -# for both real and simulated atom probe experiments it is worthwhile to recall concepts that are -# related to events and (molecular) ions: -# -# * Pulsing events which are used to trigger ion extraction events. -# * Physical events and corresponding signal triggered by an ion hitting the detector. -# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. -# * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input -# and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are -# worthwhile to be considered further and eventually included in the reconstructed volume. -# * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually -# selected (molecular) ions based on which an instance of a reconstruction is created. -# * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values -# and charge states of the (molecular) ions to substantiate that some of these ions can be considered -# as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms -# and subsequent peak labeling. In the field of atom probe this these peak identification methods -# are known as ranging definitions. -# -# Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts -# are well distinguished. However, the algorithms used to transform correlations between pulses and physical events -# into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm. -# -# Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme -# where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier -# i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. -# That is evaporation_id values take the role of an implicit time and course of the experiment given that -# ion extraction physically is a sequential process. -# -# There is a number of research groups who build own instruments and share different aspects of their technical -# specifications and approaches how they apply data processing e.g.: -# -# * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ -# * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ -# * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ -# -# to name but a few. -# -# Despite some of these activities embrace practices of open-source development, they use essentially the same -# workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface -# software is used to explore and thus analyze reconstructed atom probe datasets. -# -# Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. -# Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which -# scientific conclusions about the characterized material volume are made. Also here a reconstruction is -# point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model. -# -# By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all -# the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. -# Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. -# We argue that this divide can be bridged with realizing the above-mentioned context and the realization that -# similar concepts are used in both research realms with many concepts not only being similar but being exactly the same. -# -# A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed -# datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment -# and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting -# a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as -# (spatial) filtering and reconstruction algorithms. -# -# Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation -# simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. -# Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. -# Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. -# Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require -# simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps -# in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. -# Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) -# than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path -# such as local electrodes or physical obstacles and electric fields (controlled or stray fields). -# -# -# -# A statement whether the measurement was successful or failed prematurely. -# -# -# -# -# -# -# -# -# CAnalysis.CResults.fQuality -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Free text field for additional comments. -# -# -# -# -# -# -# Group to hold instances of :ref:`NXevent_data_apm`. -# -# Which temporal granularity is adequate depends on the situation and research -# question. Using a model which enables a collection of events offers the most -# flexible way to cater for both atom probe experiments or simulation. -# -# To monitor the course of an ion extraction experiment (or simulation) -# it makes sense to track time explicitly via time stamps or implicitly -# via e.g. a clock inside the instrument, such as the clock of the pulser -# and respective pulsing event identifier. -# -# As set and measured quantities typically change over time and we do not -# yet know during the measurement which of the events have associated -# (molecular) ions that will end up in the reconstructed volume, we must not -# document quantities as a function of the evaporation_id but as a -# function of the (pulsing) identifier_event. -# -# -# -# -# Instances should use event as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Simulation of ion extraction from matter via laser and/or voltage pulsing. -# -# -# -# -# -# A region-of-interest analyzed either during or after the session for which -# specific processed data of the measured or simulated data are available. -# -# -# -# -# SEM or TEM image of the initial specimen (ideally taken prior data acquisition). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For almost atom probe instruments (meta)data about raw data follow proprietary semantics. -# Therefore, this group can currently be used only to point to these digital artifacts -# in an effort to document all step of an analysis workflow. -# -# The physical quantities measured in an atom probe experiment are time-of-flight and -# tuples of arrival_time_pairs as a function of the event chain on the pulser. -# From these tuples hits are computed in a process called hit_finding. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The number of wires in the detector. -# -# -# -# -# -# -# -# -# -# Alias tuple (begin, end) of each DLD wire of the detector. -# Order follows arrival_time_pairs. -# -# -# -# -# -# -# -# -# Raw readings from the analog-to-digital-converter -# timing circuits of the detector wires. -# -# -# -# -# -# -# -# -# -# -# Configuration of and results obtained from a hit finding algorithm. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Evaluated ion impact coordinates on the detector. -# Use the depends_on field to specify which reference -# frame the positions are defined. -# -# -# -# -# -# -# -# Defines in which reference frame the positions are defined. -# -# -# -# -# -# CRunHeader.fTotalEventGolden -# -# -# -# -# CRunHeader.fTotalEventIncomplete -# -# -# -# -# CRunHeader.fTotalEventMultiple -# -# -# -# -# CRunHeader.fTotalEventPartials -# -# -# -# -# CRunHeader.fTotalEventRecords -# -# -# -# -# Hit quality is an integer that specifies which category/type a hit was assigned to. -# This field lists the human-readable, possibly though proprietary types distinguished. -# The indices of this array are used in hit_quality to encode hit_quality for each -# pulse in a more efficient way than by repeating the string that is used for each -# type as it is provided in this field. -# -# As an example assume two types golden and partial are distinguished. -# If hit_quality_type stores the array "golden", "partial", the index 0 -# in hit_quality identifies all those pulses of category golden, -# while the index 1 in hit_quality identifies all of category partial. -# -# -# -# -# -# -# -# Hit quality identifier for each pulse. -# Identifier have to be within hit_quality. -# -# -# -# -# -# -# -# This processing yields for each ion with how many others it evaporated -# if these were collected on the same pulse. Extraction of multiple ions -# on one pulse on different or even the same pixel of the detector are possible. -# -# Multiplicity must not be confused with how many atoms of the same element -# a molecular ion contains. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Integer used to name the first pulse to know if there is an -# offset of the evaporation_id to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# evaporation_id_offset and cardinality. For example if identifier run from -# -2 to 3 the value for evaporation_id_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where evaporation_id_offset is 1 and 0 respectively. -# -# -# -# -# (Molecular) ion identifier which resolves the sequence in which -# the ions were evaporated but taking into account that a hit_finding -# and spatial_filtering was applied. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. -# -# The voltage-and-bowl correction is a data post-processing step to correct ion impact -# positions for flight path differences, detector bias, and nonlinearities. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw time-of-flight data without corrections. -# -# -# -# -# -# -# -# -# The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate -# -# -# -# -# Calibrated time-of-flight. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses root file which stores -# the settings whereby an RHIT/HITS file can be used to regenerate the -# reconstruction that is here referred to. -# -# The respective RHIT/HITS file should ideally be specified in the serialized -# group of the hit_finding section of this application definition. -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses the resulting typically -# file with the reconstructed positions and (calibrated) mass-to-charge -# state ratio values. -# -# For other data collection/analysis software the data artifact which comes -# closest conceptually to AMETEK/Cameca's typical file formats. -# -# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, -# which should be stored alongside this record in the research data -# management system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The respective ranging definitions file RNG/RRNG/ENV/HDF5. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# (Out-of-sync) background levels in ppm/ns -# reported by e.g. IVAS/APSuite for LEAP systems. -# -# -# -# -# MRP, mass-resolving power, `D. Larson et al. -# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). -# -# -# -# -# MRP, at which mrp_value was specified. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Category for the peak offering a qualitative statement of the location of the peak -# in light of limited mass-resolving power that is relevant for -# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ -# for examples of each category: -# -# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` -# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` -# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states -# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` -# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` -# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use ion as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_measurement.yaml b/contributed_definitions/nyaml/NXapm_measurement.yaml new file mode 100644 index 0000000000..cb85304bbf --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_measurement.yaml @@ -0,0 +1,7 @@ +category: base +doc: | + Base class for documenting a measurement with an electron microscope. +type: group +NXem_measurement(NXobject): + (NXinstrument_em): + (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXapm_simulation.yaml b/contributed_definitions/nyaml/NXapm_simulation.yaml new file mode 100644 index 0000000000..433cc96620 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_simulation.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class for documenting a simulation of removing ions from a specimen and characterizing them. +type: group +NXapm_simulation(NXobject): + (NXprogram): + (NXparameters): + (NXprocess): + (NXdata): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index aed7ef0583..12964da1f4 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -153,9 +153,8 @@ NXem(NXobject): Examples are technician operating the microscope, student, postdoc, principle investigator, or guest. - SAMPLE(NXsample): + (NXsample): exists: ['min', '1', 'max', 'unbounded'] - nameType: any doc: - | A physical entity which contains material intended to be investigated. @@ -714,588 +713,552 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] doc: | Instances should use actuator as a name prefix. - events(NXevent_em): - exists: ['min', '0', 'max', '1'] - # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! - doc: | - To avoid that static instrument-related metadata need to be stored - repetitively, the NXem application definitions splits the storage of the - dynamic (meta)data that typically change for each image and spectrum - from the static one. - eventID(NXevent_data_em): - nameType: partial + eventID(NXevent_data_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + identifier_sample(NX_CHAR): + exists: recommended + # above field is another example for lacking support to define conditional existence constraints + (NXimage): exists: ['min', '0', 'max', 'unbounded'] - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - identifier_sample(NX_CHAR): + doc: | + Instances should use image as a name prefix. + Each NXimage instance must use only one image or stack instance. + (NXprocess): exists: recommended - # above field is another example for lacking support to define conditional existence constraints - (NXimage): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use image as a name prefix. - Each NXimage instance must use only one image or stack instance. - (NXprocess): + input(NXnote): exists: recommended - input(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - context(NX_CHAR): - detector_identifier(NX_CHAR): - image_1d(NXdata): + type(NX_CHAR): + file_name(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + context(NX_CHAR): + detector_identifier(NX_CHAR): + image_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_2d(NXdata): + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_3d(NXdata): + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): - exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): - exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + (NXspectrum): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use spectrum as a name prefix. + Each NXspectrum instance must use only one spectrum or stack instance. + (NXprocess): + exists: recommended + input(NXnote): + exists: recommended + type(NX_CHAR): + file_name(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + context(NX_CHAR): + detector_identifier(NX_CHAR): + spectrum_0d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_0d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + instrument(NXinstrument_em): + exists: recommended + ebeam_column(NXebeam_column): + operation_mode(NX_CHAR): + electron_source(NXsource): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): + voltage(NX_NUMBER): + extraction_voltage(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): + emission_current(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): + filament_current(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - (NXspectrum): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use spectrum as a name prefix. - Each NXspectrum instance must use only one spectrum or stack instance. - (NXprocess): - exists: recommended - input(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - context(NX_CHAR): - detector_identifier(NX_CHAR): - spectrum_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): + (NXlens_em): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use lens as a name prefix. + power_setting(NX_CHAR_OR_NUMBER): + (NXaperture): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use aperture as a name prefix. + setting(NX_CHAR_OR_NUMBER): exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): + doc: | + Descriptor for the aperture setting 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 users. + # NXaperture/size can be used as a fallback + (NXmonochromator): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use monochromator as a name prefix. + applied(NX_BOOLEAN): + dispersion(NX_NUMBER): exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): + voltage(NX_NUMBER): exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): + corrector_cs(NXcorrector_cs): + exists: ['min', '0', 'max', '1'] + applied(NX_BOOLEAN): exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - instrument(NXinstrument_em): - exists: recommended - ebeam_column(NXebeam_column): - operation_mode(NX_CHAR): - electron_source(NXsource): - exists: optional - voltage(NX_NUMBER): - extraction_voltage(NX_NUMBER): + TABLEAU(NXprocess): + nameType: any + exists: ['min', '1', 'max', 'unbounded'] + + # model(NX_CHAR): + + # ceos + doc: | + Instances should use tableau as a name prefix. + c_1(NXaberration): exists: optional - emission_current(NX_NUMBER): + magnitude(NX_NUMBER): + a_1(NXaberration): exists: optional - filament_current(NX_NUMBER): + magnitude(NX_NUMBER): + b_2(NXaberration): exists: optional - (NXlens_em): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. - power_setting(NX_CHAR_OR_NUMBER): - (NXaperture): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. - setting(NX_CHAR_OR_NUMBER): - exists: recommended - doc: | - Descriptor for the aperture setting 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 users. - - # size can be used as a fallback - (NXmonochromator): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. - applied(NX_BOOLEAN): - dispersion(NX_NUMBER): - exists: recommended - voltage(NX_NUMBER): - exists: recommended - corrector_cs(NXcorrector_cs): - exists: ['min', '0', 'max', '1'] - applied(NX_BOOLEAN): - exists: recommended - TABLEAU(NXprocess): - nameType: any - exists: ['min', '1', 'max', 'unbounded'] - - # model(NX_CHAR): - - # ceos - doc: | - Instances should use tableau as a name prefix. - c_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - d_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - r_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_6(NXaberration): - exists: optional - magnitude(NX_NUMBER): - - # nion - c_1_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - - # we could write down how to store the aberrations but we should not force to add aberrations - # basically optional use of NXaberration therein at least some value required - corrector_ax(NXcomponent): - exists: ['min', '0', 'max', '1'] - applied(NX_BOOLEAN): - value_x(NX_NUMBER): - value_y(NX_NUMBER): - - # biprism(NXcomponent): - - # phaseplateID(NXcomponent): - (NXsensor): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. - ibeam_column(NXibeam_column): + magnitude(NX_NUMBER): + a_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + d_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + r_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_6(NXaberration): + exists: optional + magnitude(NX_NUMBER): + + # nion + c_1_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + + # we could write down how to store the aberrations but we should not force to add aberrations + # basically optional use of NXaberration therein at least some value required + corrector_ax(NXcomponent): exists: ['min', '0', 'max', '1'] - ion_source(NXsource): - probe(NXatom): - voltage(NX_NUMBER): - flux(NX_NUMBER): - (NXlens_em): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. - power_setting(NX_CHAR_OR_NUMBER): - (NXaperture): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. - setting(NX_CHAR_OR_NUMBER): - doc: | - Descriptor for the aperture setting 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 users. - (NXmonochromator): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. - applied(NX_BOOLEAN): - (NXsensor): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. - (NXdetector): + applied(NX_BOOLEAN): + value_x(NX_NUMBER): + value_y(NX_NUMBER): + + # biprism(NXcomponent): + + # phaseplateID(NXcomponent): + (NXsensor): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use sensor as a name prefix. + (NXactuator): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use actuator as a name prefix. + (NXbeam): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use beam as a name prefix. + (NXdeflector): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use deflector as a name prefix. + ibeam_column(NXibeam_column): + exists: ['min', '0', 'max', '1'] + ion_source(NXsource): + probe(NXatom): + voltage(NX_NUMBER): + flux(NX_NUMBER): + (NXlens_em): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use lens as a name prefix. + power_setting(NX_CHAR_OR_NUMBER): + (NXaperture): exists: ['min', '0', 'max', 'unbounded'] doc: | - Instances should use detector as a name prefix. - mode(NX_CHAR): + Instances should use aperture as a name prefix. + setting(NX_CHAR_OR_NUMBER): doc: | - Operation mode of the detector as displayed by the control software. - scan_controller(NXscanbox_em): - exists: optional - scan_schema(NX_CHAR): - dwell_time(NX_NUMBER): + Descriptor for the aperture setting 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 users. + (NXmonochromator): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use monochromator as a name prefix. + applied(NX_BOOLEAN): (NXsensor): exists: ['min', '0', 'max', 'unbounded'] doc: | @@ -1304,31 +1267,58 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] doc: | Instances should use actuator as a name prefix. - stage(NXmanipulator): + (NXbeam): exists: ['min', '0', 'max', 'unbounded'] - design(NX_CHAR): - exists: recommended - tilt1(NX_NUMBER): - tilt2(NX_NUMBER): - rotation(NX_NUMBER): - position(NX_NUMBER): - sample_heater(NXactuator): - exists: optional - physical_quantity(NX_CHAR): - heater_current(NX_NUMBER): - exists: optional - unit: NX_CURRENT - doc: | - Nominal current of the heater. - heater_voltage(NX_NUMBER): - exists: optional - unit: NX_VOLTAGE - doc: | - Nominal voltage of the heater. - heater_power(NX_NUMBER): - unit: NX_POWER - optics(NXoptical_system_em): + doc: | + Instances should use beam as a name prefix. + (NXdeflector): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use deflector as a name prefix. + (NXdetector): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use detector as a name prefix. + mode(NX_CHAR): + doc: | + Operation mode of the detector as displayed by the control software. + scan_controller(NXscanbox_em): + exists: optional + scan_schema(NX_CHAR): + dwell_time(NX_NUMBER): + (NXsensor): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use sensor as a name prefix. + (NXactuator): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Instances should use actuator as a name prefix. + stage(NXmanipulator): + exists: ['min', '0', 'max', 'unbounded'] + design(NX_CHAR): exists: recommended + tilt1(NX_NUMBER): + tilt2(NX_NUMBER): + rotation(NX_NUMBER): + position(NX_NUMBER): + sample_heater(NXactuator): + exists: optional + physical_quantity(NX_CHAR): + heater_current(NX_NUMBER): + exists: optional + unit: NX_CURRENT + doc: | + Nominal current of the heater. + heater_voltage(NX_NUMBER): + exists: optional + unit: NX_VOLTAGE + doc: | + Nominal voltage of the heater. + heater_power(NX_NUMBER): + unit: NX_POWER + optics(NXoptical_system_em): + exists: recommended simulation(NXem_simulation): exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXem_measurement.yaml b/contributed_definitions/nyaml/NXem_measurement.yaml index 183781ce9c..cb85304bbf 100644 --- a/contributed_definitions/nyaml/NXem_measurement.yaml +++ b/contributed_definitions/nyaml/NXem_measurement.yaml @@ -1,5 +1,7 @@ category: base doc: | - Base class for ################ + Base class for documenting a measurement with an electron microscope. type: group NXem_measurement(NXobject): + (NXinstrument_em): + (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_simulation.yaml b/contributed_definitions/nyaml/NXem_simulation.yaml index c23de85afb..01c289ceaf 100644 --- a/contributed_definitions/nyaml/NXem_simulation.yaml +++ b/contributed_definitions/nyaml/NXem_simulation.yaml @@ -1,8 +1,8 @@ category: base doc: | - Base class for documenting a set of simulations of electron beam-matter interaction. + Base class for documenting a simulation of electron beam-matter interaction. type: group -NXinteraction_volume_em(NXobject): +NXem_simulation(NXobject): (NXprogram): (NXparameters): (NXprocess): diff --git a/contributed_definitions/nyaml/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml index 07c162fcbf..cc1c1295a2 100644 --- a/contributed_definitions/nyaml/NXevent_data_apm.yaml +++ b/contributed_definitions/nyaml/NXevent_data_apm.yaml @@ -4,13 +4,25 @@ doc: | Having at least one instance for an instance of NXapm is recommended. - This base class applies the concept of the NXevent_data_em base class to the specific needs + This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs of atom probe research. Against static and dynamic quantities are split to avoid a duplication of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. These pulses are identified via the pulse_id field. The point in time when each was issued is specified via the combination of start_time and delta_time. + Which temporal granularity is adequate depends on the situation and research question. + Using a model which enables a collection of events offers the most flexible way to cater for + both atom probe experiments or simulation. To monitor the course of an ion extraction experiment + (or simulation) it makes sense to track time explicitly via time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event + identifier. + + As set and measured quantities typically change over time and we do not yet know during the + measurement which of the events have associated (molecular) ions that will end up in the + reconstructed volume, we must not document quantities as a function of the evaporation_id but + as a function of the (pulsing) identifier_event. + Conceptually and technically NeXus currently stores tensorial information as arrays of values (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores a set of temperature values but that field when used somewhere is a concept. However, that diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index edbd9c5e3c..adb792840a 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -2,6 +2,18 @@ category: base doc: | Base class to store state and (meta)data of events for electron microscopy. + To avoid that static instrument-related metadata need to be stored repetitively + (for each image and spectrum) the NXem application definitions splits the + storage of the (meta)data into those that typically do not change for a session + with the microscope and those which are often different for data that is collected + with the microscope. + + Which temporal granularity is adequate to log events depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + Electron microscopes are dynamic. Scientists often report that microscopes *perform differently* across sessions. That *they* perform differently from one day or another. In some cases, root causes for performance differences @@ -10,12 +22,6 @@ doc: | bring the microscope into a state where conditions are considered better or of whatever high enough quality for starting or continuing the measurement. - Which temporal granularity is adequate to log events depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - In all these use cases it is useful to have a mechanism whereby time-dependent data of the instrument state can be stored and documented in an representation that facilitates interoperability. diff --git a/contributed_definitions/nyaml/NXevent_em.yaml b/contributed_definitions/nyaml/NXevent_em.yaml deleted file mode 100644 index 38fb866dce..0000000000 --- a/contributed_definitions/nyaml/NXevent_em.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class for grouping instances of :ref:`NXevent_data_em`. - - This group should be used to bundle all event-related (meta)data - and measured data including images and spectra. -type: group -NXevent_em(NXobject): - (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml index 88451ccfbc..34327a051e 100644 --- a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml @@ -26,7 +26,7 @@ doc: | * `S. Richter et al. `_ * `J. Bünger et al. `_ * `J. F. Ziegler et al. `_ - + type: group NXinteraction_volume_em(NXobject): (NXdata): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml index 50f93c6ba2..f5a5614d7c 100644 --- a/contributed_definitions/nyaml/NXroi.yaml +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -1,10 +1,16 @@ category: base doc: | - Base class to report on a region-of-interest of material analyzed. + Base class to report on a region-of-interest of material analyzed or simulated. Do not confuse this base class with :ref:`NXregion`. type: group NXroi(NXobject): + # generic base classes + (NXprocess): + (NXdata): + (NXimage): + (NXspectrum): + # domain-specific customizations (NXem_img): (NXem_ebsd): (NXem_eds): From 1932383cb16d45dfb2f4ae3032b7d378031d2ea3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 12:19:13 +0200 Subject: [PATCH 13/57] Completed reverting the usage of NXobject in places other than than root of an app or class def --- .../NXapm_compositionspace_config.nxdl.xml | 100 ++-- .../NXapm_compositionspace_results.nxdl.xml | 33 +- .../NXapm_measurement.nxdl.xml | 8 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 10 +- .../NXapm_reconstruction.nxdl.xml | 46 +- .../NXcs_computer.nxdl.xml | 67 ++- .../NXinstrument_em.nxdl.xml | 6 +- .../NXmicrostructure_score_config.nxdl.xml | 2 +- contributed_definitions/NXphase.nxdl.xml | 3 +- .../nyaml/NXapm_compositionspace_config.yaml | 90 ++-- .../nyaml/NXapm_compositionspace_results.yaml | 461 +----------------- .../nyaml/NXapm_measurement.yaml | 8 +- .../NXapm_paraprobe_intersector_config.yaml | 292 +---------- .../nyaml/NXapm_reconstruction.yaml | 251 +--------- .../nyaml/NXcs_computer.yaml | 156 +----- .../nyaml/NXinstrument_em.yaml | 4 +- .../nyaml/NXmicrostructure_score_config.yaml | 2 +- contributed_definitions/nyaml/NXphase.yaml | 82 ---- 18 files changed, 230 insertions(+), 1391 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index bada496613..61b2bbbfde 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -128,77 +128,71 @@ - + + + + Step during which the voxel set is segmented into voxel sets with different + chemical composition. + + - Step during which the voxel set is segmented into voxel sets with different - chemical composition. + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. - - - A principal component analysis of the chemical space to guide a decision into how many sets of voxels - with different chemical composition the machine learning algorithm suggests to split the voxel set. - - - - - The decision is guided through the evaluation of the information criterion - minimization. - - - - The maximum number of chemical classes to probe with the Gaussian mixture model - with which the voxel set is segmented into a mixture of voxels with that many different - chemical compositions. - - - - - Configuration for the Gaussian mixture model that is used in the segmentation - step. - - - - + - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. + The decision is guided through the evaluation of the information criterion + minimization. - + + + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. + + + - Configuration for the DBScan algorithm that is used in the clustering step. + Configuration for the Gaussian mixture model that is used in the segmentation + step. - - - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - - - - - The number of voxels in a neighborhood for a - voxel to be considered as a core point. - - - + + + + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. + + - TODO + Configuration for the DBScan algorithm that is used in the clustering step. - + - TODO + The maximum distance between voxel pairs in a neighborhood to be considered + connected. - - + - TODO + The number of voxels in a neighborhood for a voxel to be considered as a core + point. - + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 84271af544..6fea4c2070 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -3,7 +3,7 @@ @@ -59,14 +58,28 @@ - - + + + + + + + + - + + + Programs and libraries representing the computational environment + + + + + + + @@ -364,7 +377,7 @@ for if desired all the dependencies and libraries--> - + Respective DBScan clustering result for each segmentation/ic_opt case. @@ -410,11 +423,5 @@ for if desired all the dependencies and libraries--> - - - - - - diff --git a/contributed_definitions/NXapm_measurement.nxdl.xml b/contributed_definitions/NXapm_measurement.nxdl.xml index 37a579e7de..12c8bbcac4 100644 --- a/contributed_definitions/NXapm_measurement.nxdl.xml +++ b/contributed_definitions/NXapm_measurement.nxdl.xml @@ -21,10 +21,10 @@ # # For further information, see http://www.nexusformat.org --> - + - Base class for documenting a measurement with an electron microscope. + Base class for documenting a measurement with an atom probe microscope. - - + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 82d5ac0f12..300d0d69ef 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -3,7 +3,7 @@ diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 3378c51a5c..60c2873035 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -3,7 +3,7 @@ - Base class for reporting the description of a computer + Base class for reporting the description of a computer - Given name/alias to the computing system, e.g. MyDesktop. + Given name/alias to the computing system, e.g. MyDesktop. - Name of the operating system, e.g. Windows, Linux, Mac, Android. + 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. + 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. + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. - + - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. + Details about the system of processing units e.g. (classical) processing units (CPUs), + coprocessor, graphic cards, accelerator processing units or a system of these. - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. + Granularizing the processing units. Typical examples, a desktop computer + with a single CPU one could describe using one instance of NXcircuit. + A dual-socket server one could describe using two instances NXcircuit + A server with two dual-socket server nodes one could describe with + four instances of NXcircuit surplus a field with their level in the hierarchy. - General type of the processing unit + General type of the processing unit @@ -77,22 +77,22 @@ - Given name + Given name - + - Details about the memory system. + Details about the memory system. - Granularizing the components of the memory system. + Granularizing the components of the memory system. - Qualifier for the type of random access memory. + Qualifier for the type of random access memory. @@ -101,27 +101,27 @@ - Total amount of data which the medium can hold. + Total amount of data which the medium can hold. - Given name + Given name - + - Details about the I/O system. + Details about the I/O system. - Granularizing the components of the I/O system. + Granularizing the components of the I/O system. - Qualifier for the type of storage medium used. + Qualifier for the type of storage medium used. @@ -131,15 +131,14 @@ - Total amount of data which the medium can hold. + Total amount of data which the medium can hold. - Given name + Given name - diff --git a/contributed_definitions/NXinstrument_em.nxdl.xml b/contributed_definitions/NXinstrument_em.nxdl.xml index f0aee02a21..7c93057fc0 100644 --- a/contributed_definitions/NXinstrument_em.nxdl.xml +++ b/contributed_definitions/NXinstrument_em.nxdl.xml @@ -61,7 +61,7 @@ stresses that these types of instruments despite having several differences are still all electron beamlines with which to probe electron and/or ion matter interaction and in fact in practice have many similarities in how they are used, the components, they contain, etc. - + This field can be used in research data management systems for enabling a categorization or tagging of experiments without having to analyze if groups like NXibeam_column are present (which would indicate type is fib) or if certain lens configurations or instrument models are used @@ -96,8 +96,8 @@ on the specimen. Modern stages realize a hierarchy of components. A multi-axial tilt rotation holder is a good example where the control of each degree of freedom is technically implemented via providing instances - of either :ref:`NXpositioner`, :ref:`NXactuator`, or specialized :ref:`NXobject` - that achieve the rotating and positioning of the specimen. + of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating + and positioning of the specimen. The physical process of mounting a specimen on a stage in practice often comes with an own hierarchy of fixtures to bridge e.g. length scales technically. diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 4310195904..b21e4069d0 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -151,7 +151,7 @@ exists: optional--> - + (Mechanical) properties of the material which scale the amount of stored (elastic) energy in the system and diff --git a/contributed_definitions/NXphase.nxdl.xml b/contributed_definitions/NXphase.nxdl.xml index f75fa637d8..8ac3855445 100644 --- a/contributed_definitions/NXphase.nxdl.xml +++ b/contributed_definitions/NXphase.nxdl.xml @@ -37,7 +37,7 @@ The identifier_phase value should match with the integer suffix of the group name which represents that instance in a NeXus/HDF5 file, i.e. - if three phases were used e.g. 0, 1, and 2, three instances of + if three phases were used e.g. 0, 1, and 2, three instances of :ref:`NXphase` named phase0, phase1, and phase2 should be stored in that HDF5 file. @@ -50,7 +50,6 @@ the field name, the value should be n/a or notIndexed. - diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 1740a3db22..eff979cf0a 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -94,57 +94,51 @@ NXapm_compositionspace_config(NXobject): exists: optional doc: | Configuration for the random forest classification model. - segmentation(NXprocess): + segmentation(NXprocess): + doc: | + Step during which the voxel set is segmented into voxel sets with different + chemical composition. + pca(NXprocess): + exists: optional doc: | - Step during which the voxel set is segmented into voxel sets with different - chemical composition. - pca(NXprocess): - exists: optional - doc: | - A principal component analysis of the chemical space to guide a decision into how many sets of voxels - with different chemical composition the machine learning algorithm suggests to split the voxel set. - ic_opt(NXprocess): - doc: | - The decision is guided through the evaluation of the information criterion - minimization. - n_max_ic_cluster(NX_POSINT): - unit: NX_UNITLESS - doc: | - The maximum number of chemical classes to probe with the Gaussian mixture model - with which the voxel set is segmented into a mixture of voxels with that many different - chemical compositions. - gaussian_mixture(NXprocess): - exists: optional - doc: | - Configuration for the Gaussian mixture model that is used in the segmentation - step. - clustering(NXprocess): + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. + ic_opt(NXprocess): doc: | - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. - dbscan(NXparameters): + The decision is guided through the evaluation of the information criterion + minimization. + n_max_ic_cluster(NX_POSINT): + unit: NX_UNITLESS doc: | - Configuration for the DBScan algorithm that is used in the clustering step. - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - min_samples(NX_UINT): - unit: NX_UNITLESS - doc: | - The number of voxels in a neighborhood for a - voxel to be considered as a core point. - meshing(NXprocess): + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. + gaussian_mixture(NXprocess): + exists: optional + doc: | + Configuration for the Gaussian mixture model that is used in the segmentation step. + clustering(NXprocess): + doc: | + Step during which the chemically segmented voxel sets are analyzed for their spatial organization. + dbscan(NXparameters): doc: | - TODO - distance_cut(NX_NUMBER): + Configuration for the DBScan algorithm that is used in the clustering step. + eps(NX_FLOAT): + unit: NX_LENGTH doc: | - TODO - - # units: NX_ANY - normal_end_length(NX_NUMBER): + The maximum distance between voxel pairs in a neighborhood to be considered connected. + min_samples(NX_UINT): + unit: NX_UNITLESS doc: | - TODO - - # units: NX_ANY + The number of voxels in a neighborhood for a voxel to be considered as a core point. + # meshing(NXprocess): + # doc: | + # TODO + # distance_cut(NX_NUMBER): + # doc: | + # TODO + # units: NX_ANY + # normal_end_length(NX_NUMBER): + # doc: | + # TODO + # units: NX_ANY diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 2966783e6d..bf8603420a 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -18,24 +18,35 @@ symbols: Total number of ions in the reconstructed dataset. type: group NXapm_compositionspace_results(NXobject): - - # by default for application definitions the value of the exists keyword is required unless it is explicitly specified differently (NXentry): exists: ['min', '1', 'max', '1'] definition(NX_CHAR): \@version(NX_CHAR): exists: optional enumeration: [NXapm_compositionspace_results] - - # can be used for the name of the tool and version but also - # for if desired all the dependencies and libraries - (NXprogram): + identifier_analysis(NX_UINT): + exists: recommended + profiling(NXcs_profiling): + exists: optional + current_working_directory(NX_CHAR): + exists: recommended + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + program1(NXprogram): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - identifier_analysis(NX_UINT): + environment(NXcollection): exists: recommended - + doc: | + Programs and libraries representing the computational environment + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program(NX_CHAR): + \@version(NX_CHAR): # config config(NXnote): doc: | @@ -263,7 +274,7 @@ NXapm_compositionspace_results(NXobject): not-necessarily watertight or topologically closed objects built from individual voxels. sequence_index(NX_POSINT): enumeration: [4, 5] - ic_opt(NXobject): + ic_opt(NXprocess): doc: | Respective DBScan clustering result for each segmentation/ic_opt case. CLUSTER_ANALYSIS(NXprocess): @@ -301,435 +312,3 @@ NXapm_compositionspace_results(NXobject): specifies for which voxel in the grid clusters from this process were found. dimensions: dim: (n_voxels,) - profiling(NXcs_profiling): - exists: optional - current_working_directory(NX_CHAR): - exists: recommended - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da836d85361efa07431ace1a861fa56174dfc0a1eee62709c0a770923ed9d7dd -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the grid. -# -# -# -# -# Total number of voxels. -# -# -# -# -# Total number of ions in the reconstructed dataset. -# -# -# -# -# Application definition for results of the CompositionSpace tool used in atom probe. -# -# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ -# -# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure -# use case IUC09 that explores how to improve the organization and results storage of the -# CompositionSpace software using NeXus. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Configuration file that was used in this analysis. -# -# -# -# -# -# -# -# -# -# -# Contextualize back to the specimen from which the -# dataset was collected that was here analyzed with -# CompositionSpace tool. -# -# -# -# True, if the specimen that the reconstructed dataset -# describes is a simulated one. -# False, if the specimen that the reconstructed dataset -# describes is a real one. -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources pointed to by identifier_parent or walk through -# eventually deeply nested groups in data instances. -# -# -# -# -# -# Step during which the point cloud is discretized to compute element-specific composition fields. -# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that -# was ranged for each ion. -# -# Using a discretization grid that is larger than the average distance between reconstructed ion positions -# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods -# used in atom probe for characterizing microstructural features that use the ion position data directly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# Discrete coordinate of each voxel. -# -# -# -# -# -# -# -# -# -# For each ion, the identifier of the voxel into which the ion binned. -# -# -# -# -# -# -# -# -# Total number of weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms. -# -# -# -# -# -# -# -# -# Chemical symbol of the element from the periodic table. -# -# -# -# -# Element-specific weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms of this element. -# -# -# -# -# -# -# -# -# -# Optional step during which the subsequent segmentation step is prepared to -# improve the segmentation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Element identifier stored sorted in descending order of feature importance. -# -# -# -# -# -# -# Axis caption -# -# -# -# -# -# Element relative feature importance stored sorted in descending order of feature -# importance. -# -# -# -# -# -# -# Axis caption -# -# -# -# -# -# -# -# Step during which the voxel set is segmented into voxel sets with different -# chemical composition. -# -# -# -# PCA in the chemical space (essentially composition correlation analyses). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Explained variance values -# -# -# -# -# -# -# -# Elements identifier matching those from ENTRY/voxelization/ION -# as the principal component analysis. -# -# -# -# -# -# -# -# -# -# Information criterion minimization. -# -# -# -# -# -# -# -# -# -# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. -# -# Instances should use cluster_analysis as a name prefix. -# -# -# -# n_components argument of the Gaussian mixture model. -# -# -# -# -# y_pred return values of the computation. -# -# -# -# -# -# -# -# -# Information criterion as a function of number of n_ic_cluster aka dimensions. -# -# -# -# -# -# -# -# Akaike information criterion values -# -# -# -# -# -# -# -# Bayes information criterion values -# -# -# -# -# -# -# -# Actual n_ic_cluster values used -# -# -# -# -# -# -# -# -# -# -# Step during which the chemically segmented voxel sets are analyzed for their spatial organization -# into different spatial clusters of voxels in the same chemical set but representing individual object -# not-necessarily watertight or topologically closed objects built from individual voxels. -# -# -# -# -# -# -# -# -# -# Respective DBScan clustering result for each segmentation/ic_opt case. -# -# -# -# Instances should use cluster_analysis as a name prefix. -# -# -# -# -# The maximum distance between voxel pairs in a neighborhood -# to be considered connected. -# -# Instances should use dbscan as a name prefix. -# -# -# -# -# The number of voxels in a neighborhood for a voxel to be considered as a core -# point. -# -# -# -# -# Raw label return values -# -# -# -# -# -# -# -# Voxel identifier -# -# Using these identifiers correlated element-wise with the values in the label array -# specifies for which voxel in the grid clusters from this process were found. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_measurement.yaml b/contributed_definitions/nyaml/NXapm_measurement.yaml index cb85304bbf..0f3bb2f99a 100644 --- a/contributed_definitions/nyaml/NXapm_measurement.yaml +++ b/contributed_definitions/nyaml/NXapm_measurement.yaml @@ -1,7 +1,7 @@ category: base doc: | - Base class for documenting a measurement with an electron microscope. + Base class for documenting a measurement with an atom probe microscope. type: group -NXem_measurement(NXobject): - (NXinstrument_em): - (NXevent_data_em): +NXapm_measurement(NXobject): + (NXinstrument_apm): + (NXevent_data_apm): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 13768e7c68..98958454dc 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -81,7 +81,7 @@ NXapm_paraprobe_intersector_config(NXobject): 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(NXobject): + current_set(NXparameters): doc: | Current set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, @@ -110,7 +110,8 @@ NXapm_paraprobe_intersector_config(NXobject): 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. - (NXobject): + objectID(NXparameters): + nameType: partial exists: ['min', '1', 'max', '4'] doc: | Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the @@ -137,7 +138,7 @@ NXapm_paraprobe_intersector_config(NXobject): dimensions: rank: 1 dim: (n_variable,) - next_set(NXobject): + next_set(NXparameters): doc: | Next set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, @@ -166,7 +167,8 @@ NXapm_paraprobe_intersector_config(NXobject): 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. - (NXobject): + objectID(NXparameters): + nameType: partial exists: ['min', '1', 'max', '4'] feature_type(NX_CHAR): doc: | @@ -205,285 +207,3 @@ NXapm_paraprobe_intersector_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 90b204336d75c2a35a5cbdc8eab1afd56565b64a9ce267cdb4c0a8a9a6ba2e03 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of entries -# -# -# -# -# Application definition for a configuration file of the paraprobe-intersector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many v_v_spatial_correlation tasks should the tool execute. -# -# -# -# -# Tracking volume_volume_spatial_correlations (v_v) is the process of building logical -# relations between objects, their proximity and eventual volumetric intersections. -# Here, objects are assumed to be represented as a set of triangulated surface meshes. -# -# 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 :math:`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. -# -# Instances should use v_v_spatial_correlation as a name prefix. -# -# -# -# -# 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>`_, -# it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron -# intersections in paraprobe-intersector. -# -# -# -# -# -# -# -# Specifies if the tool evaluates if objects intersect volumetrically. -# -# -# -# -# Specifies if the tool evaluates if objects lay closer to one another than -# threshold_proximity. -# -# -# -# -# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting -# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ -# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, -# duplet, triplet, or high-order local groups. -# -# -# -# -# -# The maximum Euclidean distance between two objects below which they are -# 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 can be interpreted as the time/iteration (i.e. :math:`k`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). -# -# -# -# -# -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID 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. -# -# -# -# -# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the -# members of the set as instances of NXcg_polyhedron. -# -# -# -# Descriptive category explaining what these features are. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. -# -# -# -# -# -# Array of identifier whereby the path to the geometry data can be inferred -# 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 current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). -# -# -# -# -# -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. -# -# -# -# -# -# Array of identifier whereby the path to the geometry data can be inferred -# automatically. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml index 80c2de1c22..407cf4b677 100644 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_reconstruction.yaml @@ -82,7 +82,21 @@ NXapm_reconstruction(NXprocess): unit: NX_VOLTAGE doc: | CAnalysis.CSpatial.fVoltage0 - obb(NXobject): + protocol_name(NX_CHAR): + doc: | + Qualitative statement about which reconstruction protocol was used. + enumeration: + open_enum: true + items: [bas, geiser, gault, cameca] + crystallographic_calibration(NX_CHAR): + doc: | + Different strategies for crystallographic calibration of the + reconstruction are possible. Therefore, we collect first such + feedback before parametrizing this further. + + If no crystallographic calibration was performed, the field + should be filled with the n/a, meaning not applied. + obb(NXcollection): doc: | Tight, axis-aligned bounding box about the point cloud of the reconstruction. xmin(NX_FLOAT): @@ -109,21 +123,6 @@ NXapm_reconstruction(NXprocess): unit: NX_LENGTH doc: | TODO - protocol_name(NX_CHAR): - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: - open_enum: true - items: [bas, geiser, gault, cameca] - crystallographic_calibration(NX_CHAR): - doc: | - Different strategies for crystallographic calibration of the - reconstruction are possible. Therefore, we collect first such - feedback before parametrizing this further. - - If no crystallographic calibration was performed, the field - should be filled with the n/a, meaning not applied. - # results field_of_view(NX_FLOAT): unit: NX_LENGTH @@ -155,223 +154,3 @@ NXapm_reconstruction(NXprocess): here a 3d histogram of the ion is stored. Ion counts are characterized using one nanometer cubic bins without applying position smoothening algorithms during the histogram computation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 727135dd0aa1a8ffe91ce6226acf3f61755aefc87396981d1412e1e10b8e9b7d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# from which an instance of a reconstructed volume has been generated. -# These ions get new identifier assigned in the process - the so-called -# evaporation_id, which must not be confused with the pulse_id! -# -# -# -# -# Base class for the configuration and results of a (static) reconstruction algorithm. -# -# Generating a tomographic reconstruction of the specimen uses selected and -# 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. -# -# -# -# -# -# -# -# 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 this free-text field to guide how to parameterize this better in the -# future. For LEAP systems and reconstructions performed with IVAS/APSuite -# see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). -# -# -# -# -# CAnalysis.CSpatial.fPrimaryElement -# -# -# -# -# CAnalysis.CSpatial.fEfficiency -# -# -# -# -# CAnalysis.CSpatial.fFlightPath -# -# -# -# -# CAnalysis.CSpatial.fEvaporationField -# -# -# -# -# CAnalysis.CSpatial.fImageCompression -# -# Image compression factor (ICF) -# -# -# -# -# CAnalysis.CSpatial.fKfactor -# -# k factor -# -# -# -# -# CAnalysis.CSpatial.fRecoVolume -# -# Sum of ion volumes -# -# -# -# -# CAnalysis.CSpatial.fShankAngle -# -# Shank angle -# -# -# -# -# CAnalysis.CSpatial.fTipRadius -# -# -# -# -# CAnalysis.CSpatial.fTipRadius0 -# -# -# -# -# CAnalysis.CSpatial.fVoltage0 -# -# -# -# -# Tight, axis-aligned bounding box about the point cloud of the reconstruction. -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# -# Qualitative statement about which reconstruction protocol was used. -# -# -# -# -# -# -# -# -# -# -# Different strategies for crystallographic calibration of the -# reconstruction are possible. Therefore, we collect first such -# feedback before parametrizing this further. -# -# If no crystallographic calibration was performed, the field -# should be filled with the n/a, meaning not applied. -# -# -# -# -# -# -# The nominal diameter of the specimen ROI which is measured in the -# experiment. The physical specimen cannot be measured completely -# because ions may launch but hit in locations other than the detector. -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# -# -# -# -# -# -# -# The instance of :ref:`NXcoordinate_system` -# in which the positions are defined. -# -# -# -# -# -# -# -# -# To get a first visual overview of the reconstructed dataset, -# here a 3d histogram of the ion is stored. Ion counts are characterized -# using one nanometer cubic bins without applying position smoothening -# algorithms during the histogram computation. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index d5dba84770..9ce20bba13 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -24,7 +24,7 @@ NXcs_computer(NXobject): the Universally Unique Identifier (UUID) of the computing node. # when it comes to performance monitoring - processing(NXobject): + processing(NXnote): doc: | Details about the system of processing units e.g. (classical) processing units (CPUs), coprocessor, graphic cards, accelerator processing units or a system of these. @@ -44,7 +44,7 @@ NXcs_computer(NXobject): name(NX_CHAR): doc: | Given name - memory(NXobject): + memory(NXnote): doc: | Details about the memory system. (NXcircuit): @@ -61,7 +61,7 @@ NXcs_computer(NXobject): name(NX_CHAR): doc: | Given name - storage(NXobject): + storage(NXnote): doc: | Details about the I/O system. (NXcircuit): @@ -78,153 +78,3 @@ NXcs_computer(NXobject): name(NX_CHAR): doc: | Given name - - # NXcircuit inherits fabrication from NXcomponent - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# def5b601cc7944d9508ed1a048390db9b67fbacb57891fb83b83252ffda54459 -# -# -# -# -# -# Base class for reporting the description of a computer -# -# -# -# Given name/alias to the computing system, e.g. MyDesktop. -# -# -# -# -# Name of the operating system, e.g. Windows, Linux, Mac, Android. -# -# -# -# Version plus build number, commit hash, or description of an ever -# persistent resource where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# -# Ideally a (globally) unique persistent identifier of the computer, i.e. -# the Universally Unique Identifier (UUID) of the computing node. -# -# -# -# -# -# Details about the system of processing units e.g. (classical) processing units (CPUs), -# coprocessor, graphic cards, accelerator processing units or a system of these. -# -# -# -# Granularizing the processing units. Typical examples, a desktop computer -# with a single CPU one could describe using one instance of NXcircuit. -# A dual-socket server one could describe using two instances NXcircuit -# A server with two dual-socket server nodes one could describe with -# four instances of NXcircuit surplus a field with their level in the hierarchy. -# -# -# -# General type of the processing unit -# -# -# -# -# -# -# -# -# -# Given name -# -# -# -# -# -# -# Details about the memory system. -# -# -# -# Granularizing the components of the memory system. -# -# -# -# Qualifier for the type of random access memory. -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# -# Given name -# -# -# -# -# -# -# Details about the I/O system. -# -# -# -# Granularizing the components of the I/O system. -# -# -# -# Qualifier for the type of storage medium used. -# -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# -# Given name -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinstrument_em.yaml b/contributed_definitions/nyaml/NXinstrument_em.yaml index 96f85e5599..bebf5d689e 100644 --- a/contributed_definitions/nyaml/NXinstrument_em.yaml +++ b/contributed_definitions/nyaml/NXinstrument_em.yaml @@ -64,8 +64,8 @@ NXinstrument_em(NXinstrument): on the specimen. Modern stages realize a hierarchy of components. A multi-axial tilt rotation holder is a good example where the control of each degree of freedom is technically implemented via providing instances - of either :ref:`NXpositioner`, :ref:`NXactuator`, or specialized :ref:`NXobject` - that achieve the rotating and positioning of the specimen. + of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating + and positioning of the specimen. The physical process of mounting a specimen on a stage in practice often comes with an own hierarchy of fixtures to bridge e.g. length scales technically. diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index e1e3411515..eab96f97b4 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -82,7 +82,7 @@ NXmicrostructure_score_config(NXobject): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - material(NXobject): + material(NXparameters): doc: | (Mechanical) properties of the material which scale the amount of stored (elastic) energy in the system and diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml index 45980b33ea..163f7d0a3e 100644 --- a/contributed_definitions/nyaml/NXphase.yaml +++ b/contributed_definitions/nyaml/NXphase.yaml @@ -25,8 +25,6 @@ NXphase(NXobject): If the identifier_phase is 0 and one would like to use the field name, the value should be n/a or notIndexed. - - # group reference replaced by concept identifierNAME inherited from NXobject (NXunit_cell): (NXatom): @@ -43,83 +41,3 @@ NXphase(NXobject): (NXmicrostructure_odf): doc: | Instance names should use odf as a prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8270c365f2d0f112d6b98043c78b7edc77913f55c1f70ab4c1a389192f12c0bd -# -# -# -# -# -# Base class to describe a (thermodynamic) phase as a component of a material. -# -# Instances of phases can be crystalline. -# -# -# -# Identifier for each phase. -# -# The value 0 is reserved for the unknown phase that represents the -# null-model (no sufficiently significant information available). -# In other words, the phase_name is n/a aka notIndexed. -# -# The identifier_phase value should match with the integer suffix of the -# group name which represents that instance in a NeXus/HDF5 file, i.e. -# if three phases were used e.g. 0, 1, and 2, three instances of -# :ref:`NXphase` named phase0, phase1, and phase2 should be stored -# in that HDF5 file. -# -# -# -# -# Given name as an alias for identifying this phase. -# -# If the identifier_phase is 0 and one would like to use -# the field name, the value should be n/a or notIndexed. -# -# -# -# -# -# -# -# -# Instance names should use microstructure as a prefix. -# -# -# -# -# Instance names should use ipf as a prefix. -# -# -# -# -# Instance names should use pf as a prefix. -# -# -# -# -# Instance names should use odf as a prefix. -# -# -# From 899d07fb976089f81faa2f2faa5ccc2a58773f39 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 12:37:47 +0200 Subject: [PATCH 14/57] Reverting all cases where patterns where used like concept is of nameType: any with docstring Instances should by nameType partial and prefixID, lot 1, apm and cg --- contributed_definitions/NXapm.nxdl.xml | 10 +- .../NXapm_compositionspace_results.nxdl.xml | 13 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 6 +- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 128 +- .../NXapm_paraprobe_distancer_config.nxdl.xml | 68 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 4 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 31 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 7 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 53 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 7 +- .../NXcg_hexahedron.nxdl.xml | 10 +- .../NXcg_parallelogram.nxdl.xml | 90 +- contributed_definitions/NXcg_polygon.nxdl.xml | 95 +- .../NXcg_polyhedron.nxdl.xml | 10 +- .../NXcg_tetrahedron.nxdl.xml | 10 +- .../NXcg_triangle.nxdl.xml | 48 +- contributed_definitions/nyaml/NXapm.yaml | 10 +- .../nyaml/NXapm_compositionspace_results.yaml | 18 +- .../NXapm_paraprobe_clusterer_config.yaml | 389 +---- .../NXapm_paraprobe_clusterer_results.yaml | 299 +--- .../NXapm_paraprobe_distancer_config.yaml | 210 +-- .../NXapm_paraprobe_intersector_config.yaml | 7 +- .../NXapm_paraprobe_nanochem_results.yaml | 1306 +---------------- .../NXapm_paraprobe_spatstat_config.yaml | 349 +---- .../NXapm_paraprobe_spatstat_results.yaml | 212 +-- .../NXapm_paraprobe_surfacer_results.yaml | 301 +--- .../nyaml/NXcg_hexahedron.yaml | 210 +-- .../nyaml/NXcg_parallelogram.yaml | 112 +- .../nyaml/NXcg_polygon.yaml | 145 +- .../nyaml/NXcg_polyhedron.yaml | 133 +- .../nyaml/NXcg_tetrahedron.yaml | 93 +- .../nyaml/NXcg_triangle.yaml | 103 +- 32 files changed, 312 insertions(+), 4175 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 203391e187..a9991742a7 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -689,12 +689,9 @@ the application definition here is nothing else then the documentation of this f - + - - Instances should use event as a name prefix. - - - - Instances should use ion as a name prefix. - + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 6fea4c2070..e04a720197 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -310,11 +310,9 @@ - + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - - Instances should use cluster_analysis as a name prefix. @@ -381,17 +379,12 @@ Respective DBScan clustering result for each segmentation/ic_opt case. - - - Instances should use cluster_analysis as a name prefix. - - + + The maximum distance between voxel pairs in a neighborhood to be considered connected. - - Instances should use dbscan as a name prefix. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 4ad1bd1668..870c17f1d9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -3,7 +3,7 @@ - + This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - - Instances should use cluster_analysis as a name prefix. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 09689bc998..c1cf2bcd85 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -3,7 +3,7 @@ - + - Results of a DBScan clustering analysis. - - Instances should use dbscan as a name prefix. + Results of a DBScan clustering analysis. - The epsilon (eps) parameter used. + The epsilon (eps) parameter used. - The minimum points (min_pts) parameter used. + The minimum points (min_pts) parameter used. - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset, i.e. typically the number of clusters which is usually not and - for sure not necessarily the total number of ions in the dataset. + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily 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: - * index_offset - 1 indicates an object belongs to no cluster. - * index_offset - 2 indicates an object belongs to the noise category. - - Setting for instance index_offset to 1 recovers the commonly used - case that objects of the noise category get the value of -1 and points of the - unassigned category get the value 0. + 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: + * index_offset - 1 indicates an object belongs to no cluster. + * index_offset - 2 indicates an object belongs to the noise category. + + Setting for instance index_offset to 1 recovers the commonly used + case that objects of the noise category get the value of -1 and points of the + unassigned category get the value 0. - The evaporation (sequence) id (aka evaporation_id) to figure out - which ions from the reconstruction were considered targets. The length - of this array is not necessarily n_ions. - Instead, it is the value of cardinality. + The evaporation (sequence) id (aka evaporation_id) to figure out + which ions from the reconstruction were considered targets. The length + of this array is not necessarily n_ions. + Instead, it is the value of cardinality. @@ -116,11 +114,11 @@ - The number of solutions found for each target. Typically, - this value is 1 in which case the field can be omitted. - Otherwise, this array is the concatenated set of values of solution - tuples for each target that can be used to decode model_labels, - core_sample_indices, and weight. + The number of solutions found for each target. Typically, + this value is 1 in which case the field can be omitted. + Otherwise, this array is the concatenated set of values of solution + tuples for each target that can be used to decode model_labels, + core_sample_indices, and weight. @@ -128,12 +126,12 @@ - The raw labels from the DBScan clustering backend process. - The length of this array is not necessarily n_ions. - Instead, it is typically the value of cardinality provided that each - target has only one associated cluster. If targets are assigned to - multiple cluster this array is as long as the total number of solutions - found and + The raw labels from the DBScan clustering backend process. + The length of this array is not necessarily n_ions. + Instead, it is typically the value of cardinality provided that each + target has only one associated cluster. If targets are assigned to + multiple cluster this array is as long as the total number of solutions + found and @@ -141,8 +139,8 @@ - The raw array of core sample indices which specify which of the - targets are core points. + The raw array of core sample indices which specify which of the + targets are core points. @@ -150,7 +148,7 @@ - Numerical label for each target (member in the set) aka cluster identifier. + Numerical label for each target (member in the set) aka cluster identifier. @@ -158,7 +156,7 @@ - Categorical label(s) for each target (member in the set) aka cluster name(s). + Categorical label(s) for each target (member in the set) aka cluster name(s). @@ -166,13 +164,13 @@ - Weights for each target that specifies how probable the target is assigned to - a specific cluster. - - For the DBScan algorithm and atom probe tomography this value is 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 nuclides of requested type. + Weights for each target that specifies how probable the target is assigned to + a specific cluster. + + For the DBScan algorithm and atom probe tomography this value is 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 nuclides of requested type. @@ -180,7 +178,7 @@ - Are targets assigned to the noise category or not. + Are targets assigned to the noise category or not. @@ -188,7 +186,7 @@ - Are targets assumed a core point. + Are targets assumed a core point. @@ -196,36 +194,36 @@ - In addition to the detailed storage which members were grouped to which - feature here summary statistics are stored that communicate e.g. how many - cluster were found. + In addition to the detailed storage which members were grouped to which + feature here summary statistics are stored that communicate e.g. how many + cluster were found. - Total number of targets in the set, i.e. ions that were filtered - and considered in this cluster analysis. + Total number of targets in the set, i.e. ions that were filtered + and considered in this cluster analysis. - Total number of members in the set which are categorized as noise. + 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 members in the set which are categorized as a core point. - Total number of clusters (excluding noise and unassigned). + Total number of clusters (excluding noise and unassigned). - Numerical identifier of each feature aka cluster_id. + Numerical identifier of each feature aka cluster_id. @@ -233,7 +231,7 @@ - Number of members for each feature. + Number of members for each feature. @@ -261,7 +259,7 @@ - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 5eb81b5a73..0a78974e8b 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -3,7 +3,7 @@ + @@ -106,12 +106,12 @@ - Specifies for which point the tool will compute distances. - - The value *default* configures that distances are computed for all points. - The value *skin* configures that distances are computed only for those - points which are not farther away located to a triangle than - threshold_distance. + Specifies for which point the tool will compute distances. + + The value *default* configures that distances are computed for all points. + The value *skin* configures that distances are computed only for those + points which are not farther away located to a triangle than + threshold_distance. @@ -120,27 +120,25 @@ - Maximum distance for which distances are - computed when *method* is *skin*. + Maximum distance for which distances are + computed when *method* is *skin*. - How many triangle sets to consider. - Multiple triangle sets can be defined which are - composed into one joint triangle set for the analysis. + How many triangle sets to consider. + Multiple triangle sets can be defined which are + composed into one joint triangle set for the analysis. - + - Each triangle_set that is referred to here should be a face_list_data_structure, - i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) - array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. - Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - - Instances should use triangle_set as a name prefix. + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. @@ -148,32 +146,32 @@ - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex normal vectors for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex normal vectors for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of identifier for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of identifier for the triangles in that triangle_set. diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 300d0d69ef..27ffcdd20f 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -49,7 +49,7 @@ How many v_v_spatial_correlation tasks should the tool execute. - + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical relations between objects, their proximity and eventual volumetric intersections. @@ -60,8 +60,6 @@ step :math:`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. - - Instances should use v_v_spatial_correlation as a name prefix. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 64740d727c..aa448acc47 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -3,7 +3,7 @@ - - - Instances should use delocalization as a name prefix. - + @@ -331,7 +328,6 @@ The cardinality/total number of triangles in the triangle soup.--> 3 - mirror 4 - von Neumann 5 - Dirichlet - @@ -499,13 +495,11 @@ The cardinality/total number of triangles in the triangle soup.--> - + An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - Instances should iso_surface as a name prefix. - For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. @@ -599,7 +593,6 @@ The cardinality/total number of triangles in the triangle soup.--> * 0 - undefined * 1 - outer * 2 - inner - @@ -626,7 +619,6 @@ exists: optional--> * 0 - undefined * 1 - outer * 2 - inner - @@ -788,7 +780,6 @@ dim: (k,)--> * proxies, proxies, irrespective their distance to the surface * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - @@ -866,10 +857,7 @@ MK::namely k != i each OBB has eight vertices--> - - - Instances should use object as a name prefix. - + @@ -989,12 +977,10 @@ MK::namely k != i each OBB has eight vertices--> - + The triangle surface mesh representing the interface model. Exported at state before or after the next DCOM step. - - Instances should use mesh_state as a name prefix. @@ -1043,7 +1029,6 @@ MK::namely k != i each OBB has eight vertices--> * 0 - undefined * 1 - outer * 2 - inner - @@ -1072,7 +1057,6 @@ MK::namely k != i each OBB has eight vertices--> * 0 - undefined * 1 - outer * 2 - inner - @@ -1195,10 +1179,7 @@ MK::namely k != i each OBB has eight vertices--> are only expected to display pairwise the same values respectively, if all ions are built from a single atom only. - - - Instances should use roi as a name prefix. - + Sorted in increasing order projected along the positive direction diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 1efc23a85d..f2035670ae 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -3,7 +3,7 @@ - - - Instances should use spatial_statistics as a name prefix. - + @@ -67,13 +64,13 @@ - 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 remain the same. - - The order matches the iontypes array from a given ranging results - as it is specified in the configuration settings inside the specific - config_filename that was used for this paraprobe-spatstat analysis. + 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 remain the same. + + The order matches the iontypes array from a given ranging results + as it is specified in the configuration settings inside the specific + config_filename that was used for this paraprobe-spatstat analysis. @@ -81,11 +78,11 @@ - K-nearest neighbor statistics. + K-nearest neighbor statistics. - Right boundary of the binning. + Right boundary of the binning. @@ -98,7 +95,7 @@ - Cumulated not normalized by total counts. + Cumulated not normalized by total counts. @@ -106,7 +103,7 @@ - Cumulated and normalized by total counts. + Cumulated and normalized by total counts. @@ -115,11 +112,11 @@ - Radial distribution statistics. + Radial distribution statistics. - Right boundary of the binning. + Right boundary of the binning. @@ -132,7 +129,7 @@ - Cumulated not normalized by total counts. + Cumulated not normalized by total counts. @@ -140,7 +137,7 @@ - Cumulated and normalized by total counts. + Cumulated and normalized by total counts. @@ -173,7 +170,7 @@ - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index dc4d4d1f9b..1d7aa7dc77 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -3,7 +3,7 @@ - + - - Instances should use alpha_complex as a name prefix. - A bitmask which identifies exactly all those ions whose positions diff --git a/contributed_definitions/NXcg_hexahedron.nxdl.xml b/contributed_definitions/NXcg_hexahedron.nxdl.xml index d3442711e0..fdcc6db404 100644 --- a/contributed_definitions/NXcg_hexahedron.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron.nxdl.xml @@ -3,7 +3,7 @@ Combined storage of all primitives of all hexahedra. - + Individual storage of each hexahedron. - - Instances should use hexahedron as a name prefix. - + Individual storage of each hexahedron as a graph. - - Instances should use hexahedron_half_edge as a name prefix. diff --git a/contributed_definitions/NXcg_parallelogram.nxdl.xml b/contributed_definitions/NXcg_parallelogram.nxdl.xml index 76fa3c2c27..ba0b6af099 100644 --- a/contributed_definitions/NXcg_parallelogram.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram.nxdl.xml @@ -3,7 +3,7 @@ - To specify which parallelogram is a rectangle. + To specify which parallelogram is a rectangle. @@ -79,9 +79,9 @@ - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. @@ -90,14 +90,12 @@ - Combined storage of all parallelograms. + Combined storage of all parallelograms. - + - Individual storage of each parallelogram. - - Instances should use parallelogram as a name prefix. + Individual storage of each parallelogram. diff --git a/contributed_definitions/NXcg_polygon.nxdl.xml b/contributed_definitions/NXcg_polygon.nxdl.xml index 3288112efd..88c7b0c018 100644 --- a/contributed_definitions/NXcg_polygon.nxdl.xml +++ b/contributed_definitions/NXcg_polygon.nxdl.xml @@ -3,7 +3,7 @@ - The total number of vertices when visiting every polygon. + The total number of vertices when visiting every polygon. - Computational geometry description of a set of polygons in Euclidean space. - - Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes 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 to describe such even more complex primitives instead - of abusing this base class for such purposes. + Computational geometry description of a set of polygons in Euclidean space. + + Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes 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 to describe such even more complex primitives instead + of abusing this base class for such purposes. - The total number of vertices in the set. + The total number of vertices in the set. - Combined storage of all primitives of all polygons. + Combined storage of all primitives of all polygons. - + - Individual storage of the mesh of each polygon. - - Instances should use polygon as a name prefix. + Individual storage of the mesh of each polygon. - + - Individual storage of each polygon as a graph. - - Instances should use polygon_half_edge as a name prefix. + Individual storage of each polygon as a graph. - For each polygon its accumulated length along its edges. + For each polygon its accumulated length along its edges. @@ -105,11 +101,11 @@ - Interior angles for each polygon. There are as many values per polygon - as the are 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. + Interior angles for each polygon. There are as many values per polygon + as the are 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. @@ -117,12 +113,11 @@ - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave diff --git a/contributed_definitions/NXcg_polyhedron.nxdl.xml b/contributed_definitions/NXcg_polyhedron.nxdl.xml index d2df280a04..c5fab50ee7 100644 --- a/contributed_definitions/NXcg_polyhedron.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron.nxdl.xml @@ -3,7 +3,7 @@ Combined storage of all primitives of all polyhedra. - + Individual storage of each polyhedron. - - Instances should use polyhedron as a name prefix. - + Individual storage of each polygon as a graph. - - Instances should use cluster_analysis as a name prefix. diff --git a/contributed_definitions/NXcg_tetrahedron.nxdl.xml b/contributed_definitions/NXcg_tetrahedron.nxdl.xml index 5288d9d0f4..88651e6e07 100644 --- a/contributed_definitions/NXcg_tetrahedron.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron.nxdl.xml @@ -3,7 +3,7 @@ -# -# -# -# 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. -# -# -# -# -# Application definition for a configuration file of the paraprobe-clusterer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many cluster_analysis tasks should the tool execute. -# -# -# -# -# This process maps results from a cluster analysis made with IVAS / AP Suite -# into an interoperable representation. IVAS / AP Suite usually exports such results -# as a list of reconstructed ion positions with one cluster label per position. -# These labels are reported via the mass-to-charge-state-ratio column of what is effectively -# a binary file that is formatted like a POS file but cluster labels written out using floating -# point numbers. -# -# -# -# -# -# -# -# -# -# -# -# File with the results of the cluster analyses that was computed with IVAS / AP suite -# (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). -# The information is stored in an improper (.indexed.) POS file as a matrix of floating -# point quadruplets, one quadruplet for each ion. The first three values of each -# quadruplet encode the position of the ion. The fourth value is the integer identifier -# of the cluster encoded as a floating point number. -# -# -# -# -# -# -# -# -# Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction -# for recovering for each position in the :ref:`NXnote` results the closest matching position -# (within floating point accuracy). This can be useful when users wish to recover the -# original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster -# results POS files that is referred to results. -# -# -# -# -# -# -# This process performs a cluster analysis on a -# reconstructed dataset or a ROI within it. -# -# Instances should use cluster_analysis as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How should iontypes be considered during the cluster analysis. -# -# 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 nuclide structure. -# -# The value resolve_element will set an ion active and account as many times -# for it, as the (molecular) ion contains atoms of elements in the whitelist -# ion_query_nuclide_vector. -# -# The value resolve_isotope will set an ion active and account as many times -# for it, as the (molecular) ion contains nuclides in the whitelist -# ion_query_nuclide_vector. -# -# In effect, ion_query_nuclide_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 an ion of a molecular -# ion with more than one nuclide, say Ti O for example is counted potentially several -# times because at that position (reconstructed) position it has been assumed that -# there was a Ti and an O atom. This multiplicity affects the size of the feature and its -# chemical composition. -# -# -# -# -# -# -# -# -# Matrix of nuclide 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. -# -# -# -# -# -# -# -# -# -# Settings for DBScan clustering algorithm. For original details about the -# algorithm 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 a set of cluster analyses with different parameter is executed: -# -# * For tuple as many runs are performed as parameter values have been defined. -# * For combinatorics individual parameter arrays are looped over. -# -# As an example we may provide ten entries for eps and three entries for min_pts. -# If high_throughput_method is set to tuple, the analysis is invalid because we have -# an insufficient number of min_pts values to pair them with our ten eps values. -# By contrast, if high_throughput_method is set to combinatorics, the tool will run three -# individual min_pts runs for each eps value, resulting in a total of 30 analyses. -# -# A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ -# can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), -# one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. -# -# -# -# -# -# -# -# -# Array of epsilon (eps) parameter values. -# -# -# -# -# -# -# -# Array of minimum points (min_pts) 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 with different parameter values are composed, -# following the explanation for high_throughput_method of dbscan. -# -# -# -# -# -# -# -# -# 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_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 8fa905702a..3d32112e7d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -36,12 +36,11 @@ NXapm_paraprobe_clusterer_results(NXobject): mask(NX_UINT): # results - DBSCAN(NXsimilarity_grouping): + dbscanID(NXsimilarity_grouping): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | Results of a DBScan clustering analysis. - - Instances should use dbscan as a name prefix. eps(NX_FLOAT): unit: NX_LENGTH doc: | @@ -240,297 +239,3 @@ NXapm_paraprobe_clusterer_results(NXobject): dimensions: rank: 1 dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aa11faba17a56d3b4be4322780e2f2f940d154dcd340b4fcdb925d74cc558ad8 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Number of clusters found. -# -# -# -# -# Application definition for results files of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Results of a DBScan clustering analysis. -# -# Instances should use dbscan as a name prefix. -# -# -# -# The epsilon (eps) parameter used. -# -# -# -# -# The minimum points (min_pts) parameter used. -# -# -# -# -# Number of members in the set which is partitioned into features. -# Specifically, this is the total number of targets filtered from the -# dataset, i.e. typically the number of clusters which is usually not and -# for sure not necessarily 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: -# * index_offset - 1 indicates an object belongs to no cluster. -# * index_offset - 2 indicates an object belongs to the noise category. -# -# Setting for instance index_offset to 1 recovers the commonly used -# case that objects of the noise category get the value of -1 and points of the -# unassigned category get the value 0. -# -# -# -# -# The evaporation (sequence) id (aka evaporation_id) to figure out -# which ions from the reconstruction were considered targets. The length -# of this array is not necessarily n_ions. -# Instead, it is the value of cardinality. -# -# -# -# -# -# -# -# -# The number of solutions found for each target. Typically, -# this value is 1 in which case the field can be omitted. -# Otherwise, this array is the concatenated set of values of solution -# tuples for each target that can be used to decode model_labels, -# core_sample_indices, and weight. -# -# -# -# -# -# -# -# The raw labels from the DBScan clustering backend process. -# The length of this array is not necessarily n_ions. -# Instead, it is typically the value of cardinality provided that each -# target has only one associated cluster. If targets are assigned to -# multiple cluster this array is as long as the total number of solutions -# found and -# -# -# -# -# -# -# -# The raw array of core sample indices which specify which of the -# targets are core points. -# -# -# -# -# -# -# -# Numerical label for each target (member in the set) aka cluster identifier. -# -# -# -# -# -# -# -# Categorical label(s) for each target (member in the set) aka cluster name(s). -# -# -# -# -# -# -# -# Weights for each target that specifies how probable the target is assigned to -# a specific cluster. -# -# For the DBScan algorithm and atom probe tomography this value is 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 nuclides of requested type. -# -# -# -# -# -# -# -# Are targets assigned to the noise category or not. -# -# -# -# -# -# -# -# Are targets assumed a core point. -# -# -# -# -# -# -# -# In addition to the detailed storage which members were grouped to which -# feature here summary statistics are stored that communicate e.g. how many -# cluster were found. -# -# -# -# -# Total number of targets in the set, i.e. ions that were filtered -# and considered in this cluster analysis. -# -# -# -# -# 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). -# -# -# -# -# -# Numerical identifier of each feature aka cluster_id. -# -# -# -# -# -# -# -# Number of members for each feature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 015e6dd580..00db3c525a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -104,8 +104,8 @@ NXapm_paraprobe_distancer_config(NXobject): How many triangle sets to consider. Multiple triangle sets can be defined which are composed into one joint triangle set for the analysis. - TRIANGLE_SET(NXnote): - nameType: any + triangle_setID(NXnote): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Each triangle_set that is referred to here should be a face_list_data_structure, @@ -113,8 +113,6 @@ NXapm_paraprobe_distancer_config(NXobject): array of NX_UINT incident vertices of each facet. Vertex indices are assumed to start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - - Instances should use triangle_set as a name prefix. type(NX_CHAR): algorithm(NX_CHAR): checksum(NX_CHAR): @@ -160,207 +158,3 @@ NXapm_paraprobe_distancer_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 200950d379de89698f4f6e3cc83c5bf15af90e0f7b15a92dc9bdeaf85762d91b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Application definition for a configuration file of the paraprobe-distancer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specifies for which point the tool will compute distances. -# -# The value *default* configures that distances are computed for all points. -# The value *skin* configures that distances are computed only for those -# points which are not farther away located to a triangle than -# threshold_distance. -# -# -# -# -# -# -# -# -# Maximum distance for which distances are -# computed when *method* is *skin*. -# -# -# -# -# -# How many triangle sets to consider. -# Multiple triangle sets can be defined which are -# composed into one joint triangle set for the analysis. -# -# -# -# -# Each triangle_set that is referred to here should be a face_list_data_structure, -# i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) -# array of NX_UINT incident vertices of each facet. Vertex indices are assumed to -# start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. -# Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. -# -# Instances should use triangle_set as a name prefix. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex positions for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex indices for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex normal vectors for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of facet normal vectors for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of identifier for the triangles in that triangle_set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 98958454dc..2ca1a0c532 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -19,8 +19,8 @@ NXapm_paraprobe_intersector_config(NXobject): unit: NX_UNITLESS doc: | How many v_v_spatial_correlation tasks should the tool execute. - V_V_SPATIAL_CORRELATION(NXapm_paraprobe_tool_config): - nameType: any + v_v_spatial_correlationID(NXapm_paraprobe_tool_config): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Tracking volume_volume_spatial_correlations (v_v) is the process of building logical @@ -32,9 +32,6 @@ NXapm_paraprobe_intersector_config(NXobject): step :math:`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. - - Instances should use v_v_spatial_correlation as a name prefix. - # config intersection_detection_method(NX_CHAR): doc: | diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 11901df475..981257efa4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -40,10 +40,9 @@ NXapm_paraprobe_nanochem_results(NXobject): enumeration: [NXapm_paraprobe_nanochem_results] # tasks - (NXdelocalization): + delocalizationID(NXdelocalization): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use delocalization as a name prefix. + nameType: partial window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -382,14 +381,13 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (i,) # MK:: - (NXisocontour): + iso_surfaceID(NXisocontour): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - Instances should iso_surface as a name prefix. - For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. @@ -722,11 +720,9 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensions: rank: 1 dim: (k,) - OBJECT(NXcg_polyhedron): - nameType: any + objectID(NXcg_polyhedron): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use object as a name prefix. polyhedron(NXcg_face_list_data_structure): vertices(NX_FLOAT): unit: NX_LENGTH @@ -833,14 +829,12 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensions: rank: 1 dim: (4,) - MESH_STATE(NXcg_triangle): - nameType: any + mesh_stateID(NXcg_triangle): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | The triangle surface mesh representing the interface model. Exported at state before or after the next DCOM step. - - Instances should use mesh_state as a name prefix. state(NX_CHAR): doc: | Was this state exported before or after the next DCOM step. @@ -1013,11 +1007,9 @@ NXapm_paraprobe_nanochem_results(NXobject): Therefore, the XDMF support fields number_of_atoms and number_of_ions are only expected to display pairwise the same values respectively, if all ions are built from a single atom only. - ROI(NXcg_roi): - nameType: any + roiID(NXcg_roi): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use roi as a name prefix. signed_distance(NX_FLOAT): unit: NX_LENGTH doc: | @@ -1079,1281 +1071,3 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensions: rank: 1 dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d950192a3b3217d1444ddddf207d1e840ca6743ca8f47143c52b04faf92e288c -# -# -# -# -# -# -# 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 faces of triangles. -# -# -# -# -# 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 volumetric features. -# -# -# -# -# The total number of member distinguished when reporting composition. -# -# -# -# -# The total number of ROIs placed in an oned_profile task. -# -# -# -# -# Application definition for results files of the paraprobe-nanochem tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# Instances should use delocalization as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How were results of the kernel-density estimation normalized: -# * total, the total number (intensity) of ions or elements. -# * candidates, the total number (intensity) of ions matching weighting_model -# * composition, the value for candidates divided by the value for total, -# * concentration, the value for candidates divided by the volume of the cell. -# -# -# -# -# -# -# -# -# -# -# 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-dimensional base 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. -# -# -# -# -# -# -# -# -# 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 :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Functional form of the kernel (Ansatz function). -# -# -# -# -# -# -# -# Standard deviation :math:`\sigma_i` 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 :math:`\mu_i` of the kernel in each dimension -# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. -# -# -# -# -# -# -# -# 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 -# :math:`[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 -# :math:`[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 -# :math:`[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: :math:`[\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 :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces -# will be computed. In commercial software so far there is no possibility to export this information. -# -# If the intensity for all matches of the weighting_model are summarized name this NXdata instance -# scalar_field_magn_total. -# -# If the intensity is reported for each iontype one can avoid many subsequent -# computations as individual intensities can be reinterpreted using a different weighting_model in -# down-stream usage of the here reported values (e.g. with Python scripting). -# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as -# per the configuration of the ranging definitions used. -# -# -# -# -# -# -# -# -# -# The actual delocalized intensity values. -# -# -# -# -# -# -# -# -# -# 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 XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# The three-dimensional gradient :math:`\nabla \Phi`. -# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. -# -# -# -# -# -# -# -# -# -# The actual point-wise component values. -# -# -# -# -# -# -# -# -# -# -# Cell center of mass positions along x. -# -# -# -# -# -# -# -# Cell center of mass positions along y. -# -# -# -# -# -# -# -# Cell center of mass positions along z. -# -# -# -# -# -# -# -# The gradient vector formatted for direct visualization via XDMF in e.g. -# Paraview. -# -# -# -# -# -# -# -# -# Center of mass positions of each voxel for rendering the scalar field gradient -# via XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# XDMF topology for rendering in combination with xdmf_xyz the scalar field -# via XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# -# An iso-surface is the boundary between two regions across which the magnitude of a -# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. -# -# Instances should iso_surface as a name prefix. -# -# For applications in atom probe microscopy, the location and shape of such a boundary (set) -# is typically approximated by discretization - triangulation to be specific. -# -# 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 :math:`\varphi`. -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to a unique set as this may -# result in 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 each -# vertex is stored even though many share the same positions. -# -# -# -# -# -# -# -# -# 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: :math:`[\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. -# :math:`\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 the 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 representation of such iso-surface. -# This may yield a set of connected features whose individual surfaces are discretized -# by a triangulated mesh each. Such volumetric features can be processed further using -# paraprobe-nanochem using a workflow with at most two steps. -# -# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: -# -# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. -# These objects were already watertight within the triangulated iso-surface. -# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated -# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh -# processing operations (hole filling, refinement, fairing operations). -# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality -# that are not transformable into proxies or for which no transformation into proxies was -# instructed. -# -# 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. -# -# In the second step, the tool can be used to analyze the proximity of these objects to a -# model of the surface (edge) of the dataset. -# -# -# -# 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. -# -# -# -# -# -# -# -# In all situations instances of the parent NXprocess group are returned with a very similar -# information structuring and thus we here replace the template name FEATURE -# with one of the following types feature-specific group names: -# -# * objects, objects, irrespective their distance to the surface -# * objects_close_to_edge, sub-set of v_feature_object close surface -# * objects_far_from_edge, sub-set of v_feature_object not close to the surface -# * proxies, proxies, irrespective their distance to the surface -# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface -# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface -# -# -# -# -# Explicit identifier of the feature a sub-set of the indices_feature in the -# parent group. -# -# -# -# -# -# -# -# Volume of the feature. NaN for non-watertight objects. -# -# -# -# -# -# -# -# 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 or second-largest over largest and smallest over second largest. -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Instances should use object as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_id / identifier_ion which details which ions -# lie inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# Total (count) of ions inside or on the surface of the feature relevant for normalization. -# NaN for non watertight objects. -# -# -# -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total, yields the composition of this element, -# nuclide, or (molecular) ion within the volume of the feature/object. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# 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 fitted initially. -# -# -# -# The four parameter :math:`ax + by + cz + d = 0` which define the plane. -# -# -# -# -# -# -# -# -# The triangle surface mesh representing the interface model. -# Exported at state before or after the next DCOM step. -# -# Instances should use mesh_state as a name prefix. -# -# -# -# Was this state exported before or after the next DCOM step. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each vertex normal. -# -# -# -# -# -# -# -# -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each face normal. -# -# -# -# -# -# -# -# -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 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 we discretize -# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, -# resolves the lateral surface of each cylinder such that their renditions are smooth in -# visualization software like Paraview. -# -# -# -# -# -# Position of the geometric center, which often is but not -# necessarily has to be the center_of_mass of the polyhedra. -# -# -# -# -# -# -# -# -# The orientation of the ROI defined via a vector which points along -# the cylinder axis and whose length is the height of the cylinder. -# -# -# -# -# -# -# -# -# -# XDMF support to enable coloring each ROI by its identifier. -# -# -# -# -# -# -# -# XDMF support to enable coloring each ROI whether it has edge contact or not. -# -# -# -# -# -# -# -# XDMF support to enable coloring each ROI by its number of atoms. -# -# -# -# -# -# -# -# XDMF support to enable coloring each ROI by its number of ions. -# -# -# -# -# -# -# -# Distance and iontype-specific processed data for each ROI. -# Arrays signed_distance and nuclide_hash are sorted by increasing -# distance. -# Array nuclide_hash reports one hash for each atom of each isotope. -# Effectively, this can yield to groups of values on signed_distance -# with the same distance value as molecular ions are reported decomposed -# into their atoms. -# Therefore, the XDMF support fields number_of_atoms and number_of_ions -# are only expected to display pairwise the same values respectively, -# if all ions are built from a single atom only. -# -# -# -# Instances should use roi as a name prefix. -# -# -# -# Sorted in increasing order projected along the positive direction -# of the ROI as defined by orientation in the parent group. -# -# -# -# -# -# -# -# Hashvalue as defined in :ref:`NXion`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index f513ec60b9..2088a4803b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -23,11 +23,9 @@ NXapm_paraprobe_spatstat_config(NXobject): unit: NX_UNITLESS doc: | How many spatial_statistics tasks should the tool execute. - SPATIAL_STATISTICS(NXapm_paraprobe_tool_config): - nameType: any + spatial_statisticsID(NXapm_paraprobe_tool_config): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] - doc: | - Instances should use spatial_statistics as a name prefix. identifier_analysis(NX_UINT): exists: recommended reconstruction(NXnote): @@ -266,346 +264,3 @@ NXapm_paraprobe_spatstat_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60357bb9e6a1e5ad0e17322c6d3cda6c930022f7e1ee84712fcfed49ad377771 -# -# -# -# -# -# -# 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 source iontypes to distinguish. -# -# -# -# -# Number of different target iontypes to distinguish. -# -# -# -# -# Application definition for a configuration file of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many spatial_statistics tasks should the tool execute. -# -# -# -# -# Instances should use spatial_statistics as a name prefix. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# -# Threshold to define how far an ion has to lay at least from the edge -# of the dataset so that the ion can act as a source. This means that -# an ROI is placed at the location of the ion and its neighbors are -# analyzed how they contribute to the computed statistics. -# -# The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a -# microstructural feature an ROI is placed. -# -# The threshold is useful to process the dataset such that ROIs do -# not protrude out of the dataset as this would add bias. -# -# -# -# -# -# Distance between each ion and triangulated mesh of microstructural features. -# 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 the feature_distance -# threshold value. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file which points to the distance of each -# ion to the closest feature. -# -# -# -# -# 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 this feature_distance threshold is used in combination -# with the edge_distance threshold when placing ROI about source ions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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 -# iontypes randomly across the entire set of ions. That is the total -# number of ions of either type remain the same but the information about -# their location is randomized. -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# 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_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 1f3a830410..f285cd4790 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -21,11 +21,9 @@ NXapm_paraprobe_spatstat_results(NXobject): enumeration: [NXapm_paraprobe_spatstat_results] # tasks - SPATIAL_STATISTICS(NXapm_paraprobe_tool_results): - nameType: any + spatial_statisticsID(NXapm_paraprobe_tool_results): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use spatial_statistics as a name prefix. window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -151,209 +149,3 @@ NXapm_paraprobe_spatstat_results(NXobject): dimensions: rank: 1 dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2589235a1654399d2f93642b153dc0f2b28c3ec8164f566997f47802e047643a -# -# -# -# -# -# -# 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 bins in the histogram for the k-th nearest neighbor. -# -# -# -# -# The total number of bins in the histogram for the radial distribution function. -# -# -# -# -# Application definition for results files of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# Instances should use spatial_statistics as a name prefix. -# -# -# -# -# -# -# -# -# -# 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 remain the same. -# -# The order matches the iontypes array from a given ranging results -# as it is specified in the configuration settings inside the specific -# config_filename that was used for this paraprobe-spatstat analysis. -# -# -# -# -# -# -# -# K-nearest neighbor statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated not normalized by total counts. -# -# -# -# -# -# -# -# Cumulated and normalized by total counts. -# -# -# -# -# -# -# -# -# Radial distribution statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated not normalized by total counts. -# -# -# -# -# -# -# -# Cumulated and normalized by total counts. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 148e2bf41f..3615f6ae12 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -51,14 +51,12 @@ NXapm_paraprobe_surfacer_results(NXobject): mask(NX_UINT): # results - ALPHA_COMPLEX(NXcg_alpha_complex): - nameType: any + alpha_complexID(NXcg_alpha_complex): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] # (NXcg_grid): currently we do not store the underlying grid # for eventually performed preprocessing - doc: | - Instances should use alpha_complex as a name prefix. window(NXcs_filter_boolean_mask): doc: | A bitmask which identifies exactly all those ions whose positions @@ -218,298 +216,3 @@ NXapm_paraprobe_surfacer_results(NXobject): dimensions: rank: 1 dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 76304ef075492d347e86ff81f03576460015c8e07852b382c88baf747879b06a -# -# -# -# -# -# -# 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. -# -# -# -# -# Application definition for results files of the paraprobe-surfacer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-surfacer tool is the generation of meshed -# representation of the surface of the the reconstructed volume (or a portion) of it -# using different algorithms from the computational geometry community. -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# Instances should use alpha_complex as a name prefix. -# -# -# -# A bitmask which identifies exactly all those ions whose positions -# were considered when defining the filtered point set from which -# that alpha_complex instance was computed. -# -# This window can be different to the window of the *point_set_wrapping* -# parent group because irrelevant ions might have been filtered out in addition -# to the window defined in *point_set_wrapping* to reduce e.g. computational -# costs of the alpha complex computation. -# -# -# -# -# Number of ions covered by the mask. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# -# -# -# -# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for -# how this bitfield is to be interpreted. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The set of triangles in the coordinate system paraprobe -# which discretizes the exterior surface of the alpha complex. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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 that is watertight? -# -# -# -# -# The volume which the triangulated surface mesh -# encloses if that mesh is watertight. -# -# -# -# -# -# -# The set of tetrahedra which represent the interior volume -# of the complex if that is a closed two-manifold. -# -# -# -# -# The accumulated volume of all interior tetrahedra. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_hexahedron.yaml b/contributed_definitions/nyaml/NXcg_hexahedron.yaml index 55f55a8198..da1d3ffd7f 100644 --- a/contributed_definitions/nyaml/NXcg_hexahedron.yaml +++ b/contributed_definitions/nyaml/NXcg_hexahedron.yaml @@ -138,213 +138,11 @@ NXcg_hexahedron(NXcg_primitive): hexahedra(NXcg_face_list_data_structure): doc: | Combined storage of all primitives of all hexahedra. - HEXAHEDRON(NXcg_face_list_data_structure): - nameType: any + hexahedronID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each hexahedron. - - Instances should use hexahedron as a name prefix. - HEXAHEDRON_HALF_EDGE(NXcg_half_edge_data_structure): - nameType: any + hexahedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial doc: | Individual storage of each hexahedron as a graph. - - Instances should use hexahedron_half_edge as a name prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e2ccf5cb709c2a56bbf5ccaa145046d39aab23421ade9e81860e5fa6e7fa81a5 -# -# -# -# -# -# -# -# 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. -# -# 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 an approach whereby -# different specific views can be implemented using the same base class: -# -# * In the simplest case experimentalists may use this base class to describe -# the dimensions or size of a specimen. In this case the alignment with axes -# is not relevant as eventually only the volume of the specimen is of interest. -# * In many cases, take for example an experiment where a specimen was cut out -# from a specifically deformed piece of material, the orientation of the -# specimen's edges with the experiment coordinate system is of high relevance. -# Examples include knowledge about the specimen edge, whether it is -# parallel to the rolling, the transverse, or the normal direction. -# * While the above-mentioned use cases are sufficient to pinpoint the sample -# within a known laboratory/experiment coordinate system, these descriptions -# are not detailed enough to specify e.g. a CAD model of the specimen. -# * Therefore, groups and fields for an additional, computational-geometry- -# based view of hexahedra is offered to serve additional 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. -# -# As a specialization of the :ref:`NXcg_primitive` base class hexahedra -# are assumed non-degenerated, closed, and built of polygons that are -# not self-intersecting. -# -# The term hexahedra will be used throughout this base class but includes -# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), -# and optimal bounding box (OBB). -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a cuboid whose edges are aligned with the -# base vectors of a coordinate system. As a part of binary trees, these data -# objects are important for making 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 -# tightly fitting box about an arbitrary object. In general, such boxes are -# rotated. Exact and substantially faster in practice approximate algorithms -# exist to compute optimal or near optimal bounding boxes for sets of points. -# -# -# -# -# Qualifier for the shape of each hexahedron. -# -# -# -# -# -# -# -# -# Qualifier that is useful in cases when one edge is longer than all other -# edges of the hexahedra. Often the term length is associated with the -# assumption that one edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the horizontal -# direction assuming a specific coordinate system. -# -# For the sake of explicitness quantities like length, width, and height -# should not be reported without specifying also the assumed reference frame. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the vertical -# direction assuming a specific coordinate system. -# -# -# -# -# -# -# -# Volume of each hexahedron. -# -# -# -# -# -# -# -# Total (surface) 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 coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all hexahedra. -# -# -# -# -# Individual storage of each hexahedron. -# -# Instances should use hexahedron as a name prefix. -# -# -# -# -# Individual storage of each hexahedron as a graph. -# -# Instances should use hexahedron_half_edge as a name prefix. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram.yaml b/contributed_definitions/nyaml/NXcg_parallelogram.yaml index f83f1e5c1c..2e90b0787b 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram.yaml +++ b/contributed_definitions/nyaml/NXcg_parallelogram.yaml @@ -62,115 +62,7 @@ NXcg_parallelogram(NXcg_primitive): parallelograms(NXcg_face_list_data_structure): doc: | Combined storage of all parallelograms. - PARALLELOGRAM(NXcg_face_list_data_structure): - nameType: any + parallelogramID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each parallelogram. - - Instances should use parallelogram as a name prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 17922a6f78b7e30c708098c850b30a7c8fe2ba43bdcaa3e394782cb2cb514753 -# -# -# -# -# -# -# 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. -# -# This class can also be used to describe rectangles or squares, irrespective -# whether these are axis-aligned or not. The class represents different -# access and description levels to embrace applied scientists and computational -# geometry experts with their different views: -# -# * The simplest case is the communication of dimensions aka the size of a -# region of interest in the 2D plane. In this case, communicating the -# alignment with axes is maybe not as relevant as it is to report the area -# of the ROI. -# * In other cases the extent of the parallelogram is relevant though. -# * Finally, in CAD models it should be possible to specify the polygons -# which the parallelograms represent with exact numerical details. -# -# Parallelograms are important geometrical primitives as their usage for -# describing many scanning experiments shows where typically parallelogram-shaped -# ROIs are scanned across the surface of a sample. -# -# The term parallelogram will be used throughout this base class thus including -# the important special cases rectangle, square, 2D box, axis-aligned bounding box -# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D -# counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a rectangle whose edges are aligned with the -# axes of a coordinate system. As a part of binary trees AABBs are important data -# objects for executing 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, i.e. -# most tightly 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 an optimal bounding box to a point set in 2D. -# -# -# -# -# To specify which parallelogram is a rectangle. -# -# -# -# -# -# -# -# Only to be used if is_rectangle is present. In this case, this field -# describes whether parallelograms are rectangles whose primary edges -# are parallel to the axes of the coordinate system. -# -# -# -# -# -# -# -# -# Combined storage of all parallelograms. -# -# -# -# -# Individual storage of each parallelogram. -# -# Instances should use parallelogram as a name prefix. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polygon.yaml b/contributed_definitions/nyaml/NXcg_polygon.yaml index efc9f6d00f..4af45fe7da 100644 --- a/contributed_definitions/nyaml/NXcg_polygon.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon.yaml @@ -47,19 +47,14 @@ NXcg_polygon(NXcg_primitive): polygons(NXcg_face_list_data_structure): doc: | Combined storage of all primitives of all polygons. - POLYGON(NXcg_face_list_data_structure): - nameType: any + polygonID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of the mesh of each polygon. - - Instances should use polygon as a name prefix. - POLYGON_HALF_EDGE(NXcg_half_edge_data_structure): + polygon_half_edgeID(NXcg_half_edge_data_structure): nameType: any doc: | Individual storage of each polygon as a graph. - - Instances should use polygon_half_edge as a name prefix. - # properties of the polygon primitives edge_length(NX_NUMBER): unit: NX_LENGTH @@ -90,137 +85,3 @@ NXcg_polygon(NXcg_primitive): dimensions: rank: 1 dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8c9fc1ce7afe05d6d24acc8e928677470a1b760fb9993a6de023897554cf079d -# -# -# -# -# -# -# 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed -# polyhedra. Even more general complexes can be thought of. An example are the -# so-called piecewise-linear complexes used in the TetGen library. -# -# As these complexes 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 to describe such even more complex primitives instead -# of abusing this base class for such purposes. -# -# -# -# The total number of vertices in the set. -# -# -# -# -# -# Combined storage of all primitives of all polygons. -# -# -# -# -# Individual storage of the mesh of each polygon. -# -# Instances should use polygon as a name prefix. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# Instances should use polygon_half_edge as a name prefix. -# -# -# -# -# -# For each polygon its accumulated length along its edges. -# -# -# -# -# -# -# -# Interior angles for each polygon. There are as many values per polygon -# as the are 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 -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron.yaml b/contributed_definitions/nyaml/NXcg_polyhedron.yaml index 0cf11153ff..608ab74bb7 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron.yaml @@ -63,136 +63,11 @@ NXcg_polyhedron(NXcg_primitive): polyhedra(NXcg_face_list_data_structure): doc: | Combined storage of all primitives of all polyhedra. - POLYHEDRON(NXcg_face_list_data_structure): - nameType: any + polyhedronID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each polyhedron. - - Instances should use polyhedron as a name prefix. - POLYHEDRON_HALF_EDGE(NXcg_half_edge_data_structure): - nameType: any + polyhedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial doc: | Individual storage of each polygon as a graph. - - Instances should use cluster_analysis as a name prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 120c28ea7aaba11c216033c9576a1b068e7fecea8980a5c376648a1098c7cfc6 -# -# -# -# -# -# -# -# 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 set of polyhedra in Euclidean space. -# -# Polyhedra or so-called cells (especially in the convex of tessellations) are -# constructed from polygon meshes. Polyhedra may make contact to allow a usage -# of this base class for a description of tessellations. -# -# For the description of more complicated manifolds and especially for polyhedra -# with holes, users are advised to check if their particular needs are described -# by creating customized instances of an :ref:`NXcg_polygon`. -# -# -# -# -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. -# -# -# -# -# -# -# -# Area of each of faces. -# -# -# -# -# -# -# -# The number of edges for each polyhedron. Edges of adjoining polyhedra -# are counted for each polyhedron. -# -# -# -# -# Length of each edge. -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all polyhedra. -# -# -# -# -# Individual storage of each polyhedron. -# -# Instances should use polyhedron as a name prefix. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# Instances should use cluster_analysis as a name prefix. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron.yaml index 2d1ac9fb21..436a09b09d 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron.yaml @@ -31,98 +31,11 @@ NXcg_tetrahedron(NXcg_primitive): tetrahedra(NXcg_face_list_data_structure): doc: | Combined storage of all primitives of all tetrahedra. - TETRAHEDRON(NXcg_face_list_data_structure): - nameType: any + tetrahedronID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each tetrahedron. - - Instances should use tetrahedron as a name prefix. - TETRAHEDRON_HALF_EDGE(NXcg_half_edge_data_structure): + tetrahedron_half_edgeID(NXcg_half_edge_data_structure): nameType: any doc: | Individual storage of each tetrahedron as a graph. - - Instances should use tetrahedron_half_edge as a name prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c1255f54620b49caebdeea01968b86940a0832576bcd7a858bec41ffb9bf6c9f -# -# -# -# -# -# -# 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. -# -# Among hexahedral elements, tetrahedral elements are one of the most -# frequently used geometric primitive for meshing and describing volumetric -# objects in continuum-field simulations. -# -# -# -# -# Area of each of the four triangular faces of each tetrahedron. -# -# -# -# -# -# -# -# -# Length of each edge of each tetrahedron. -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all tetrahedra. -# -# -# -# -# Individual storage of each tetrahedron. -# -# Instances should use tetrahedron as a name prefix. -# -# -# -# -# Individual storage of each tetrahedron as a graph. -# -# Instances should use tetrahedron_half_edge as a name prefix. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_triangle.yaml b/contributed_definitions/nyaml/NXcg_triangle.yaml index aeb3829112..53ab5d4af0 100644 --- a/contributed_definitions/nyaml/NXcg_triangle.yaml +++ b/contributed_definitions/nyaml/NXcg_triangle.yaml @@ -22,14 +22,12 @@ NXcg_triangle(NXcg_primitive): This description resembles the typical representation of primitives in file formats such as OFF, PLY, VTK, or STL. - TRIANGLE(NXcg_face_list_data_structure): - nameType: any + triangleID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each triangle. Users are advised that using such individual storage of primitives may be less storage efficient than creating a combined storage. - - Instances should use triangle as a name prefix. edge_length(NX_NUMBER): unit: NX_LENGTH doc: | @@ -50,100 +48,3 @@ NXcg_triangle(NXcg_primitive): dimensions: rank: 2 dim: (c, 3) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f0778e02cfc0f25c83c5790cb2e0636da7fb916eacd22e68bd7198fb9a824b06 -# -# -# -# -# -# -# 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. -# -# -# -# Number of unique vertices in the triangle set. -# -# -# -# -# Combined storage of all primitives of all triangles. -# -# This description resembles the typical representation of primitives -# in file formats such as OFF, PLY, VTK, or STL. -# -# -# -# -# Individual storage of each triangle. -# Users are advised that using such individual storage of primitives -# may be less storage efficient than creating a combined storage. -# -# Instances should use triangle as a name prefix. -# -# -# -# -# Length of the edges of each triangle. -# -# For each triangle values are reported via traversing -# the vertices in the sequence as these are defined. -# -# -# -# -# -# -# -# -# Interior angles of each triangle. -# -# For each triangle values are reported for the angle opposite -# to the respective edges in the sequence how vertices are defined. -# -# -# -# -# -# -# From 87b856947cebf9d43afb553b72891a0120ffffc1 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 12:39:02 +0200 Subject: [PATCH 15/57] Removal of obsolete NXcoordinate_system_set to reflect how the discussion with the NIAC when specifically as documented in https://github.com/nexusformat/definitions/pull/1415/files --- .../NXcoordinate_system_set.nxdl.xml | 236 ---------- .../nyaml/NXcoordinate_system_set.yaml | 415 ------------------ 2 files changed, 651 deletions(-) delete mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.yaml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index 36d58e9337..0000000000 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,236 +0,0 @@ - - - - - - - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - - - - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the - base vectors of this coordinate system as Xp, Yp, Zp. - - - - - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the - base vectors of this coordinate system as Xs, Ys, Zs. - - - - - Details about the detector_reference_frame for a specific detector. - - Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Instances should use detector_reference_frame as a name prefix. - - - diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml deleted file mode 100644 index 76bb47265e..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ /dev/null @@ -1,415 +0,0 @@ -category: base -doc: | - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas `_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - -# express conventions explicitly and understandable -# use depends_on field - not attribute - to point to conventions used -type: group -NXcoordinate_system_set(NXobject): - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference ``_. - - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation according to convention 3 - of reference ``_. - enumeration: [passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference ``_. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference ``_. - enumeration: [rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference ``_. - enumeration: [p_plus_one, p_minus_one] - - # possibility to add further coordinate systems - (NXcoordinate_system): - - # frequently used coordinate systems with frequently relevant specializations follow - # convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system - processing_reference_frame(NXcoordinate_system): - doc: | - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference ``_ suggests to label the - base vectors of this coordinate system as Xp, Yp, Zp. - sample_reference_frame(NXcoordinate_system): - doc: | - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference ``_ suggests to label the - base vectors of this coordinate system as Xs, Ys, Zs. - DETECTOR_REFERENCE_FRAME(NXcoordinate_system): - nameType: any - doc: | - Details about the detector_reference_frame for a specific detector. - - Reference ``_ suggests to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Instances should use detector_reference_frame as a name prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8a9fdb972479b9335272557cc99009c964a33a69c698a3ac5d16a3c8ea84eeff -# -# -# -# -# -# -# Base class to hold different coordinate systems and representation conversions. -# -# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? -# -# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across -# the application definition, an instance of NXcoordinate_system is defined, -# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ -# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and -# NXcoordinate_system base classes backwards compatible to older -# NeXus conventions and classes. -# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed -# as high up in the node hierarchy (ideally right below an instance of NXentry) -# of the application definition tree as possible. -# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system -# instance. This shall be named such that it is clear how this coordinate system is -# typically referred to in a community. For the NeXus `McStas coordinate system, it is -# advised to call it mcstas for the sake of improved clarity. -# Additional NXcoordinate_system instances should be specified if possible in that same -# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. -# -# If this is the case, it is assumed that the NXcoordinate_system_members -# overwrite the NeXus default McStas coordinate system, i.e. users can thereby -# conveniently and explicitly specify the coordinate system(s) that -# they wish to use. -# -# Users are encouraged to write also explicit and clean depends_on fields in -# all groups that encode information about where the interpretation of coordinate -# systems is relevant. If these depends_on hints are not provided, it is -# automatically assumed that all children (to arbitrary depth) -# of that branch and sub-branches below the one in which that -# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set -# instance in that set or the application definition is considered -# underconstrained which should at all costs be avoided and in which case -# again McStas is assumed. -# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified -# somewhere in the tree, different interpretations are possible as to which -# of these coordinate system sets and instances apply or take preference. -# We realize that such ambiguities should at all costs be avoided. -# However, the opportunity for multiple sets and their instances enables to -# have branch-specific coordinate system conventions which could especially -# be useful for deep classes where multiple scientific methods are combined or -# cases where having a definition of global translation and conversion tables -# how to convert between representations in different coordinate systems -# is not desired or available for now. -# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective -# NXcoordinate_system instances makes the interpretation eventually unnecessary -# complicated. Instead, developers of application definitions should always try -# to work for clarity and thus use only one top-level coordinate system set. -# -# For these reasons we conclude that the option with one top-level -# :ref:`NXcoordinate_system_set` instance is the preferred choice. -# -# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance -# of NXcoordinate_system is specified. However, even in this case it is better -# to be explicit like for every other coordinate system definition to support -# users with interpreting the content and logic behind every instance of the tree. -# -# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? -# Individual coordinate systems should be specified as members of the -# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. -# -# How many individual instances of NXcoordinate_system to allow within one -# instance of :ref:`NXcoordinate_system_set`? -# -# * 0; This case should be avoided for the sake of clarity but this case could -# mean the authors of the definition meant that McStas is used. We conclude, -# McStas is used in this case. -# * 1; Like above-mentioned this case has the advantage that it is explicit -# and faces no ambiguities. However, in reality typically multiple -# coordinate systems have to be mastered especially for complex -# multi-signal modality experiments. -# * 2 or more; If this case is realized, the best practice is that in every -# case where a coordinate system should be referred to the respective class -# has a depends_on field which resolves the possible ambiguities which specific -# coordinate systems is referred to. The benefit of this explicit and clear -# specifying of the coordinate system used in every case is that especially -# in combination with having coordinate systems inside deeper branches -# makes up for a very versatile, backwards compatible, but powerful system -# to express different types of coordinate systems using NeXus. In the case -# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, -# it is also advised to specify the relationship between the two coordinate systems by -# using the (NXtransformations) group within NXcoordinate_system. -# -# In effect, 1 should be the preferred choice. However, if more than one coordinate -# system is defined for practical purposes, explicit depends_on fields should -# always guide the user for each group and field which of the coordinate system -# one refers to. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin. -# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parametrizations/representations according -# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# -# -# -# Details about eventually relevant named directions that may give reasons for anisotropies. -# The classical example is mechanical processing where one has to specify which directions -# (e.g. rolling, transverse, and normal direction) align how with the direction of the base -# vectors of the sample_reference_frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the -# base vectors of this coordinate system as Xp, Yp, Zp. -# -# -# -# -# Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the -# base vectors of this coordinate system as Xs, Ys, Zs. -# -# -# -# -# Details about the detector_reference_frame for a specific detector. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the -# base vectors of this coordinate system as Xd, Yd, Zd. -# -# It is assumed that the configuration is inspected by looking towards the sample surface -# from a position that is located behind the detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Instances should use detector_reference_frame as a name prefix. -# -# -# From 826a978880ea73e0b79bb18ad572e5eed8488742 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 12:44:54 +0200 Subject: [PATCH 16/57] Reverting nameType any to partial pattern, lot 2 microstructures --- contributed_definitions/NXmicrostructure.nxdl.xml | 6 +----- .../NXmicrostructure_gragles_results.nxdl.xml | 9 ++------- .../NXmicrostructure_imm_results.nxdl.xml | 5 +---- .../NXmicrostructure_kanapy_results.nxdl.xml | 5 +---- .../NXmicrostructure_score_results.nxdl.xml | 9 ++------- contributed_definitions/nyaml/NXmicrostructure.yaml | 2 -- .../nyaml/NXmicrostructure_gragles_results.yaml | 11 ++++------- .../nyaml/NXmicrostructure_imm_results.yaml | 5 ++--- .../nyaml/NXmicrostructure_kanapy_results.yaml | 5 ++--- .../nyaml/NXmicrostructure_score_results.yaml | 11 ++++------- 10 files changed, 19 insertions(+), 49 deletions(-) diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 63c488e6ff..51c6f06ad8 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -297,11 +297,7 @@ examples for specific frequently discussed microstructural features--> First identifier whereby to identify phases implicitly. - - - Instances should use phase as a prefix. - - + diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index 7290012d6d..813a8637d9 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -92,11 +92,9 @@ - + Documentation of the spatiotemporal evolution - - Instances should use spatiotemporal as a name prefix. @@ -219,10 +217,7 @@ the typical lean summary statistics flattened--> - - - Instances should use microstructure as a name prefix. - + diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index c073f4cc11..0d2be01617 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -78,10 +78,7 @@ - - - Instances should use microstructure as a name prefix. - + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 1eea74b602..e381ccbab1 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -92,10 +92,7 @@ - - - Instances should use microstructure as a name prefix. - + diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 4ec4448d4a..fb62d0367c 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -244,15 +244,13 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - + Documentation of the spatiotemporal evolution for each CA domain. SCORE is a hybrid parallelized code that can evolve multiple replicas in parallel. The set of replicas is distributed across MPI processes. Each such replica is then evolved via OpenMP multi-threading. - - Instances should use spatiotemporal as a name prefix. @@ -380,10 +378,7 @@ Applied external electrical field on the ROI. unit: NX_ANY dim: (n_summary_stats, 3, 3) the typically storage-costlier snapshot data--> - - - Instances should use microstructure as a name prefix. - + diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index f6ca8ea682..8caa715d8d 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -212,8 +212,6 @@ NXmicrostructure(NXobject): doc: | First identifier whereby to identify phases implicitly. (NXphase): - doc: | - Instances should use phase as a prefix. crystals(NXmicrostructure_feature): doc: | One- or two-dimensional projections, or three-dimensional representations of crystals. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 6dbb0ac6ca..b85096d6b0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -51,12 +51,10 @@ NXmicrostructure_gragles_results(NXobject): y_direction: z_alias: z_direction: - SPATIOTEMPORAL(NXprocess): - nameType: any + spatiotemporalID(NXprocess): + nameType: partial doc: | Documentation of the spatiotemporal evolution - - Instances should use spatiotemporal as a name prefix. # static quantities for which no change is modelled # the typical lean summary statistics flattened @@ -150,10 +148,9 @@ NXmicrostructure_gragles_results(NXobject): dim: (n_summary_stats, 3, 3) # the typically storage-costlier snapshot data - (NXmicrostructure): + microstructureID(NXmicrostructure): exists: ['min', '1', 'max', 'unbounded'] - doc: | - Instances should use microstructure as a name prefix. + nameType: partial time(NX_NUMBER): iteration(NX_INT): temperature(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index 2e2b8db213..fbe32506ac 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -44,9 +44,8 @@ NXmicrostructure_imm_results(NXobject): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - (NXmicrostructure): - doc: | - Instances should use microstructure as a name prefix. + microstructureID(NXmicrostructure): + nameType: partial grid(NXcg_grid): extent(NX_UINT): cell_dimensions(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 3679e641d2..13e391e4fb 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -53,10 +53,9 @@ NXmicrostructure_kanapy_results(NXobject): \@version(NX_CHAR): # no units instead labelled-property graph concepts with units - (NXmicrostructure): + microstructureID(NXmicrostructure): exists: ['min', '1', 'max', 'unbounded'] - doc: | - Instances should use microstructure as a name prefix. + nameType: partial grid(NXcg_grid): extent(NX_UINT): cell_dimensions(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index de91877535..924291447c 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -149,8 +149,8 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (6,) - SPATIOTEMPORAL(NXprocess): - nameType: any + spatiotemporalID(NXprocess): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Documentation of the spatiotemporal evolution for each CA domain. @@ -158,8 +158,6 @@ NXmicrostructure_score_results(NXobject): SCORE is a hybrid parallelized code that can evolve multiple replicas in parallel. The set of replicas is distributed across MPI processes. Each such replica is then evolved via OpenMP multi-threading. - - Instances should use spatiotemporal as a name prefix. # the typical lean summary statistics flattened summary_statistics(NXprocess): @@ -265,10 +263,9 @@ NXmicrostructure_score_results(NXobject): # unit: NX_ANY # dim: (n_summary_stats, 3, 3) # the typically storage-costlier snapshot data - (NXmicrostructure): + microstructureID(NXmicrostructure): exists: ['min', '1', 'max', 'unbounded'] - doc: | - Instances should use microstructure as a name prefix. + nameType: partial time(NX_FLOAT): iteration(NX_UINT): unit: NX_UNITLESS From e1455162de56ae0adcfc454d8c5a444435b4dbb0 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 12:55:53 +0200 Subject: [PATCH 17/57] Reverting nameType any to partial pattern, last lot NXem --- contributed_definitions/NXem.nxdl.xml | 236 +++++------------------- contributed_definitions/nyaml/NXem.yaml | 223 +++++++++------------- 2 files changed, 133 insertions(+), 326 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 4d4f1e9120..ce6be2f455 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -133,7 +133,7 @@ but for practical purposes currently is interpretable only by human to provide t - + Information about persons who performed or were involved in the microscope session or simulation run. @@ -145,8 +145,6 @@ but for practical purposes currently is interpretable only by human to provide t The protection of personal data by laws is in different stages of development and strictness. Therefore, the existence of user data has not been made required. - - Instances should use user as a name prefix. @@ -187,7 +185,7 @@ but for practical purposes currently is interpretable only by human to provide t - + A physical entity which contains material intended to be investigated. Sample and specimen are treated as de facto synonyms. @@ -562,8 +560,6 @@ but for practical purposes currently is interpretable only by human to provide t Reference to the specifically named :ref:`NXdetector` instance for which these conventions apply (e.g. /entry1/instrument/detector1). - - Instances should use detector_reference_frame as a name prefix. @@ -649,11 +645,9 @@ hence using optional is sufficient--> - + Details about the control program used for operating the microscope. - - Instances should use control_software as a name prefix. @@ -675,10 +669,7 @@ hence using optional is sufficient--> - - - Instances should use lens as a name prefix. - + @@ -686,10 +677,7 @@ hence using optional is sufficient--> - - - Instances should use aperture as a name prefix. - + @@ -697,10 +685,7 @@ hence using optional is sufficient--> - - - Instances should use monochromator as a name prefix. - + @@ -722,20 +707,14 @@ hence using optional is sufficient--> - - - Instances should use biprism as a name prefix. - + - - - Instances should use phaseplate as a name prefix. - + @@ -743,26 +722,10 @@ hence using optional is sufficient--> - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + - - - Instances should use lens as a name prefix. - + @@ -795,10 +755,7 @@ which components that microscope was built from--> - - - Instances should use aperture as a name prefix. - + @@ -806,10 +763,7 @@ which components that microscope was built from--> - - - Instances should use monochromator as a name prefix. - + @@ -817,31 +771,12 @@ which components that microscope was built from--> - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + - - - Instances should use detector as a name prefix. - + @@ -872,31 +807,19 @@ which components that microscope was built from--> - - - Instances should use pump as a name prefix. - + - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - + + - + - Instances should use image as a name prefix. Each NXimage instance must use only one image or stack instance. @@ -1072,9 +995,8 @@ which components that microscope was built from--> - + - Instances should use spectrum as a name prefix. Each NXspectrum instance must use only one spectrum or stack instance. @@ -1241,16 +1163,10 @@ which components that microscope was built from--> - - - Instances should use lens as a name prefix. - + - - - Instances should use aperture as a name prefix. - + Descriptor for the aperture setting when the exact technical details @@ -1261,22 +1177,16 @@ which components that microscope was built from--> - - - Instances should use monochromator as a name prefix. - + - + - - Instances should use tableau as a name prefix. - @@ -1406,26 +1316,10 @@ basically optional use of NXaberration therein at least some value required--> - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + @@ -1433,16 +1327,10 @@ basically optional use of NXaberration therein at least some value required--> - - - Instances should use lens as a name prefix. - + - - - Instances should use aperture as a name prefix. - + Descriptor for the aperture setting when the exact technical details @@ -1452,37 +1340,15 @@ basically optional use of NXaberration therein at least some value required--> - - - Instances should use monochromator as a name prefix. - + - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - - - - Instances should use beam as a name prefix. - - - - - Instances should use deflector as a name prefix. - - + + + + - - - Instances should use detector as a name prefix. - + Operation mode of the detector as displayed by the control software. @@ -1493,16 +1359,8 @@ basically optional use of NXaberration therein at least some value required--> - - - Instances should use sensor as a name prefix. - - - - - Instances should use actuator as a name prefix. - - + + @@ -1581,9 +1439,8 @@ an RDM can be sure to find specific pieces of information in a specific way but then every user of this application definition is required to provide such information in this way!--> - + - Instances should use image as a name prefix. Each NXimage instance must use only one image or stack instance. @@ -1637,10 +1494,7 @@ is required to provide such information in this way!--> - - - Instances should use phase as a name prefix. - + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 12964da1f4..2fa0df96a3 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -105,8 +105,9 @@ NXem(NXobject): file_name(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - (NXuser): + userID(NXuser): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | Information about persons who performed or were involved in the microscope session or simulation run. @@ -118,8 +119,6 @@ NXem(NXobject): The protection of personal data by laws is in different stages of development and strictness. Therefore, the existence of user data has not been made required. - - Instances should use user as a name prefix. identifierNAME(NX_CHAR): nameType: partial exists: recommended @@ -153,8 +152,9 @@ NXem(NXobject): Examples are technician operating the microscope, student, postdoc, principle investigator, or guest. - (NXsample): + sampleID(NXsample): exists: ['min', '1', 'max', 'unbounded'] + nameType: partial doc: - | A physical entity which contains material intended to be investigated. @@ -417,8 +417,6 @@ NXem(NXobject): doc: | Reference to the specifically named :ref:`NXdetector` instance for which these conventions apply (e.g. /entry1/instrument/detector1). - - Instances should use detector_reference_frame as a name prefix. alias(NX_CHAR): exists: optional type(NX_CHAR): @@ -472,12 +470,11 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXprogram): + programID(NXprogram): exists: recommended + nameType: partial doc: | Details about the control program used for operating the microscope. - - Instances should use control_software as a name prefix. program(NX_CHAR): \@version(NX_CHAR): ebeam_column(NXebeam_column): @@ -500,10 +497,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXlens_em): + lensID(NXlens_em): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. + nameType: partial name(NX_CHAR): fabrication(NXfabrication): exists: optional @@ -511,10 +507,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXaperture): + apertureID(NXaperture): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. + nameType: partial name(NX_CHAR): fabrication(NXfabrication): exists: optional @@ -522,10 +517,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXmonochromator): + monochromatorID(NXmonochromator): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. + nameType: partial type(NX_CHAR): fabrication(NXfabrication): exists: optional @@ -549,22 +543,18 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - BIPRISM(NXcomponent): - nameType: any + biprismID(NXcomponent): + nameType: partial exists: ['min', '0', 'max', '1'] - doc: | - Instances should use biprism as a name prefix. fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - PHASEPLATE(NXcomponent): - nameType: any + phaseplateID(NXcomponent): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use phaseplate as a name prefix. type(NX_CHAR): fabrication(NXfabrication): exists: recommended @@ -572,22 +562,17 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): + beamID(NXbeam): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): + deflectorID(NXdeflector): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. ibeam_column(NXibeam_column): exists: ['min', '0', 'max', '1'] @@ -611,10 +596,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXlens_em): + lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. name(NX_CHAR): fabrication(NXfabrication): exists: optional @@ -622,10 +606,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXaperture): + apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. name(NX_CHAR): fabrication(NXfabrication): exists: optional @@ -633,10 +616,9 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXmonochromator): + monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -645,26 +627,21 @@ NXem(NXobject): exists: recommended # device for correcting axial astigmatism of ion beam? - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): + beamID(NXbeam): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): + deflectorID(NXdeflector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. - (NXdetector): + detectorID(NXdetector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use detector as a name prefix. name(NX_CHAR): fabrication(NXfabrication): exists: recommended @@ -700,19 +677,16 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - (NXpump): + pumpID(NXpump): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use pump as a name prefix. design(NX_CHAR): - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. eventID(NXevent_data_em): nameType: partial exists: ['min', '0', 'max', 'unbounded'] @@ -723,10 +697,10 @@ NXem(NXobject): identifier_sample(NX_CHAR): exists: recommended # above field is another example for lacking support to define conditional existence constraints - (NXimage): + imageID(NXimage): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | - Instances should use image as a name prefix. Each NXimage instance must use only one image or stack instance. (NXprocess): exists: recommended @@ -891,10 +865,10 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - (NXspectrum): + spectrumID(NXspectrum): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | - Instances should use spectrum as a name prefix. Each NXspectrum instance must use only one spectrum or stack instance. (NXprocess): exists: recommended @@ -1047,15 +1021,13 @@ NXem(NXobject): exists: optional filament_current(NX_NUMBER): exists: optional - (NXlens_em): + lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. power_setting(NX_CHAR_OR_NUMBER): - (NXaperture): + apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. setting(NX_CHAR_OR_NUMBER): exists: recommended doc: | @@ -1064,10 +1036,9 @@ NXem(NXobject): the microscope does not enable or was not configured to display these values for users. # NXaperture/size can be used as a fallback - (NXmonochromator): + monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. applied(NX_BOOLEAN): dispersion(NX_NUMBER): exists: recommended @@ -1077,15 +1048,13 @@ NXem(NXobject): exists: ['min', '0', 'max', '1'] applied(NX_BOOLEAN): exists: recommended - TABLEAU(NXprocess): - nameType: any + tableauID(NXprocess): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] # model(NX_CHAR): # ceos - doc: | - Instances should use tableau as a name prefix. c_1(NXaberration): exists: optional magnitude(NX_NUMBER): @@ -1217,68 +1186,55 @@ NXem(NXobject): # biprism(NXcomponent): # phaseplateID(NXcomponent): - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): + beamID(NXbeam): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): + deflectorID(NXdeflector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. ibeam_column(NXibeam_column): exists: ['min', '0', 'max', '1'] ion_source(NXsource): probe(NXatom): voltage(NX_NUMBER): flux(NX_NUMBER): - (NXlens_em): + lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use lens as a name prefix. power_setting(NX_CHAR_OR_NUMBER): - (NXaperture): + apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use aperture as a name prefix. setting(NX_CHAR_OR_NUMBER): doc: | Descriptor for the aperture setting 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 users. - (NXmonochromator): + monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use monochromator as a name prefix. applied(NX_BOOLEAN): - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. - (NXbeam): + beamID(NXbeam): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use beam as a name prefix. - (NXdeflector): + deflectorID(NXdeflector): exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use deflector as a name prefix. - (NXdetector): + detectorID(NXdetector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use detector as a name prefix. mode(NX_CHAR): doc: | Operation mode of the detector as displayed by the control software. @@ -1286,14 +1242,12 @@ NXem(NXobject): exists: optional scan_schema(NX_CHAR): dwell_time(NX_NUMBER): - (NXsensor): + sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use sensor as a name prefix. - (NXactuator): + actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use actuator as a name prefix. stage(NXmanipulator): exists: ['min', '0', 'max', 'unbounded'] design(NX_CHAR): @@ -1377,10 +1331,10 @@ NXem(NXobject): # is required to provide such information in this way! img(NXem_img): exists: optional - (NXimage): + imageID(NXimage): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | - Instances should use image as a name prefix. Each NXimage instance must use only one image or stack instance. imaging_mode(NX_CHAR): (NXmicrostructure): @@ -1436,10 +1390,9 @@ NXem(NXobject): # per scan point quantities (identifier_phase, matching_phase, positions, etc.) # just using the implicit optional, for the database example in NOMAD we do # not wish to duplicate all payload data - (NXphase): + phaseID(NXphase): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: | - Instances should use phase as a name prefix. name(NX_CHAR): exists: recommended number_of_scan_points(NX_UINT): From 5b84653450ba6f810d25ab1fa6a3d3484223e906 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 13:04:41 +0200 Subject: [PATCH 18/57] Addressed phyy-nxx comment on using American spelling throughout --- contributed_definitions/NXem.nxdl.xml | 2 +- .../NXem_calorimetry.nxdl.xml | 12 +- contributed_definitions/NXem_ebsd.nxdl.xml | 20 +- contributed_definitions/nyaml/NXem.yaml | 2 +- .../nyaml/NXem_calorimetry.yaml | 12 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 693 +----------------- 6 files changed, 30 insertions(+), 711 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ce6be2f455..20cdd45371 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1457,7 +1457,7 @@ is required to provide such information in this way!--> - + diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index a7af3b743a..4aaceb6dd3 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -194,14 +194,14 @@ used for indices_pattern. dim: (n_p,)--> - Computation of the centre for each pattern using e.g. a Circular Hough + Computation of the center for each pattern using e.g. a Circular Hough Transformation. - Computed centre for each pattern. + Computed center for each pattern. @@ -212,7 +212,7 @@ dim: (n_p,)--> - Elliptical distortion correction as a step when computing the centre for + Elliptical distortion correction as a step when computing the center for patterns. @@ -220,7 +220,7 @@ dim: (n_p,)--> NXcg_ellipsoid--> - Computed centre for each pattern. + Computed center for each pattern. @@ -231,7 +231,7 @@ NXcg_ellipsoid--> - Integrated diffraction pattern intensity as a function of radial distance from the centre + Integrated diffraction pattern intensity as a function of radial distance from the center azimuthally integrated as a function of time. @@ -250,7 +250,7 @@ NXcg_ellipsoid--> Integrated intensity as a function of time and the radial distance from the - pattern centre. + pattern center. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index ade63a5774..64dd488738 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -3,7 +3,7 @@ + + +--> An overview of the entire ROI. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 2fa0df96a3..39c71aef26 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1351,7 +1351,7 @@ NXem(NXobject): x_direction(NX_CHAR): y_direction(NX_CHAR): z_direction(NX_CHAR): - pattern_centre(NXprocess): + pattern_center(NXprocess): exists: recommended x_boundary_convention(NX_CHAR): x_normalization_direction(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index 843372336e..b8061ae358 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -145,7 +145,7 @@ NXem_calorimetry(NXobject): # dim: (n_p,) pattern_center(NXprocess): doc: | - Computation of the centre for each pattern using e.g. a Circular Hough + Computation of the center for each pattern using e.g. a Circular Hough Transformation. sequence_index(NX_POSINT): @@ -153,7 +153,7 @@ NXem_calorimetry(NXobject): position(NX_FLOAT): unit: NX_LENGTH doc: | - Computed centre for each pattern. + Computed center for each pattern. dimensions: rank: 2 dim: (n_p, 2) @@ -162,7 +162,7 @@ NXem_calorimetry(NXobject): distortion_correction(NXprocess): exists: optional doc: | - Elliptical distortion correction as a step when computing the centre for + Elliptical distortion correction as a step when computing the center for patterns. sequence_index(NX_POSINT): @@ -171,7 +171,7 @@ NXem_calorimetry(NXobject): center(NX_NUMBER): unit: NX_LENGTH doc: | - Computed centre for each pattern. + Computed center for each pattern. dimensions: rank: 2 dim: (n_p, 2) @@ -179,7 +179,7 @@ NXem_calorimetry(NXobject): # \@units: 1/nm integration(NXprocess): doc: | - Integrated diffraction pattern intensity as a function of radial distance from the centre + Integrated diffraction pattern intensity as a function of radial distance from the center azimuthally integrated as a function of time. sequence_index(NX_POSINT): @@ -201,7 +201,7 @@ NXem_calorimetry(NXobject): unit: NX_UNITLESS doc: | Integrated intensity as a function of time and the radial distance from the - pattern centre. + pattern center. dimensions: rank: 2 dim: (n_p, n_f) diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index d9ebe493ae..99cca23f1e 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -122,7 +122,7 @@ NXem_ebsd(NXprocess): Reference ``_ suggests to assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. - enumeration: [in_the_pattern_centre] + enumeration: [in_the_pattern_center] x_direction(NX_CHAR): doc: | Direction of the positively pointing x-axis base vector of the @@ -138,9 +138,9 @@ NXem_ebsd(NXprocess): Direction of the positively pointing z-axis base vector of the gnomonic_reference_frame. enumeration: [north, east, south, west, in, out] - pattern_centre(NXprocess): + pattern_center(NXprocess): doc: | - Details about the definition of the pattern centre as a special point in the + Details about the definition of the pattern center as a special point in the gnomonic_reference_frame. Typically the gnomonic space is embedded in the detector space. @@ -161,7 +161,7 @@ NXem_ebsd(NXprocess): x_boundary_convention(NX_CHAR): doc: | From which border of the EBSP (in the detector reference frame) is the pattern - centre's x-position (PCx) measured. + center's x-position (PCx) measured. enumeration: [top, right, bottom, left] x_normalization_direction(NX_CHAR): doc: | @@ -171,7 +171,7 @@ NXem_ebsd(NXprocess): y_boundary_convention(NX_CHAR): doc: | From which border of the EBSP (in the detector reference frame) is the pattern - centre's y-position (PCy) measured. + center's y-position (PCy) measured. enumeration: [top, right, bottom, left] y_normalization_direction(NX_CHAR): doc: | @@ -435,7 +435,7 @@ NXem_ebsd(NXprocess): scan_point_positions(NX_NUMBER): unit: NX_LENGTH doc: | - Calibrated centre positions of each scan point + Calibrated center positions of each scan point in the sample surface reference system. dimensions: rank: 2 @@ -494,684 +494,3 @@ NXem_ebsd(NXprocess): \@long_name(NX_CHAR): doc: | Label for the x axis - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a306e20b2f387d4d3fcb42935565f404b4681bdc633b821ee0679e2222f22d48 -# -# -# -# -# -# -# -# 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 plot orientation mapping. -# -# -# -# -# Number of pixel along slow changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of pixel along fast changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of phase solutions -# -# -# -# -# Number of reflectors (Miller crystallographic plane triplets). -# -# -# -# -# Base class method-specific for Electron Backscatter Diffraction (EBSD). -# -# The general procedure of an EBSD experiment is as follows: -# Users load the specimen, collect first a coarse image of the surface. -# Next, they set an approximate value for the calibrated working distance -# and tilt the stage into diffraction conditions. -# -# Users then typically configure the microscope for collecting quality data. -# The EBSD detector is pushed in (if retractable). Subsequently, they fine tune -# the illumination and aberration corrector settings and select one or multiple ROIs -# for the microscope to machine off automatically. They configure on-the-fly -# indexing parameter and then typically start the measurement queue. -# From this point onwards typically the microscope runs automatically. -# -# Diffraction pattern get collected until the queue finishes or gets interrupted by -# either errors or arrival at the end of the users' allocated timeslot at the instrument. -# -# Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. -# Once indexed, these patterns are often not stored. -# -# Results are stored in files, which afterwards are typically copied -# automatically or manually for archival purposes to certain storage -# locations for further consumption. The result of such an EBSD -# measurement/experiment is a set of usually proprietary or open files -# from technology partners. -# -# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific -# data, metadata, and connections between these for the research field of -# electron microscopy exemplified here for electron backscatter diffraction (EBSD). -# The base class solves two key documentation issues within the EBSD community: -# -# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted -# according to NXem_ebsd) stores the connection between the microscope session and -# the key datasets which are considered typically results of the afore-mentioned -# steps involved in an EBSD experiment. -# -# Different groups in NXem_ebsd make connections to data artifacts which were collected -# when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, -# associated overview images, like secondary electron or backscattered electron -# images of the region-of-interest probed, and many more (meta)data. -# -# Secondly, NXem_ebsd connects and stores the conventions and reference frames -# which were used and which are the key to a correct mathematical interpretation -# of every experiment or simulation using EBSD. -# -# Otherwise, results would be ripped out of their context like it is the current situation -# with many traditional studies where EBSD data were indexed on-the-fly and shared -# with the community only via sharing the strongly processed files with results in some -# formatting but without communicating all conventions used or just relying on the assumptions -# that colleagues likely know these conventions even though -# multiple definitions are possible. -# -# NXem_ebsd 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) experiments -# where a combination of repetitive removal of material from the surface layer to measure -# otherwise the same region-of-interest at different depth increments. Material removal -# can be achieved with mechanical, electron, or ion polishing, using manual steps or -# automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. -# -# Three-dimensional experiments require to follow a sequence of specimen, surface -# preparation, and data collection steps. By virtue of design, these methods are destructive -# either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. -# -# Eventual tomography methods also use such a workflow because first diffraction -# images are collected (e.g. with X-ray) and then these images are indexed to process -# a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint -# also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. -# -# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. -# -# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 -# -# -# -# Details about the gnomonic (projection) reference frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions are not met, the user is required to explicitly state this. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the -# base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. -# -# -# -# Origin of the gnomonic_reference_frame. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to -# assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the definition of the pattern centre as a special point in the -# gnomonic_reference_frame. -# -# Typically the gnomonic space is embedded in the detector space. -# Specifically, the XgYg plane is defined such that it is 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 -# one effectively normalizes in fractions of the width of the detector. -# -# The issue with terms like width and height, though, is that these become degenerated -# if the detector region-of-interest is square-shaped. This is why instead of referring to -# width and height it is better to state explicitly which direction is considered positive -# when measuring distances. -# -# For the concepts used to specify the boundary_convention it is assumed that the -# region-of-interest is defined by a rectangle, referring to the direction of outer-unit -# normals to the respective edges of this rectangle. -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's x-position (PCx) measured. -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the x-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's y-position (PCy) measured. -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the y-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# -# This group documents relevant details about the conditions and the -# tools for measuring diffraction patterns with an electron microscope. -# -# The most frequently collected EBSD data are captured for rectangular -# regions-of-interest using a discretization into square or hexagon tiles. -# -# -# -# Physical time since the beginning of a timestamp that is required to be -# the same for all experiments in the set. The purpose of this marker is -# to identify how all experiments in the set need 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, -# 30 minutes, 6 hours, or 24 hours of annealing. -# -# -# -# Timestamp relative to which time was counted to aid -# converting between time and timestamp. -# -# -# -# -# -# Path to an instance of :ref:`NXdata` where the measured patterns are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent data artifact which -# stores either the measured patterns or input (already processed EBSD data). -# -# -# -# -# -# This group documents relevant details about the conditions and the tools -# used for simulating diffraction patterns with some physical model. -# -# This group should be used if (e.g. instead of a measurement) the patterns -# were simulated (possibly awaiting indexing). -# -# In many practical cases where patterns are analyzed on-the-fly and dictionary -# indexing strategies used, so-called master pattern(s) are used to compare -# measured or simulated patterns with the master patterns. -# -# -# -# Path to an instance of :ref:`NXimage` where the simulated patterns are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent digital resource which -# stores either the patterns or input (already processed EBSD data) that are -# about to become processed further as described by this NXem_ebsd instance. -# -# -# -# -# -# The EBSD system, including components like the electron gun, pole-piece, -# stage tilt, EBSD detector, and the gnomonic projection have to be -# calibrated to achieve reliable, precise, and accurate scientific results. -# -# Specifically, the gnomonic projection has to be calibrated. -# Typically, standard specimens made from silicon or quartz crystals -# in specific orientations are used for this purpose. -# -# Considering that a system used is already calibrated well-enough is much -# more frequently the case in practice than that users perform the calibration -# themselves (with above-mentioned standard specimens). -# -# 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 has been calibrated already. Consequently, users pick from -# an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. -# Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). -# -# In the second case, users calibrate the system during the session -# using standards (silicon, quartz, or other common specimens). -# There is usually one person in each lab responsible for doing such -# calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, -# the conventions how orientations are stored is affected by how the -# reference frames are configured and how this setup in the GUI. -# -# 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' obligation to remember these -# settings or write these down in a lab notebook. Otherwise, these metadata -# get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` -# solves in that all conventions can be specified explicitly. -# -# -# -# Path to an instance of :ref:`NXem` where calibration data are stored. -# -# -# -# -# Reference to a digital resource where the calibration is stored. -# -# -# -# -# -# Indexing is a data processing step performed either after or while (aka on-the-fly) -# the beam scans the specimen. The resulting method is also -# known as orientation imaging microscopy (OIM). -# -# Different algorithms can be used to index EBSP. Common to them is the -# computational step where simulated or theoretically assumed patterns -# are compared with the measured ones. These latter patterns are referred -# to via the measurement or simulation groups of this base class respectively. -# -# Quality descriptors are defined based on which an indexing algorithm -# yields a quantitative measure of how similar measured and reference -# patterns are, and thus if no, one, or multiple so-called solutions were found. -# -# Assumed or simulated patterns are simulated using kinematical or dynamical -# theory of electron diffraction delivering master patterns. -# -# The Hough transform, one of the most frequently used traditional method for indexing -# EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods -# find more widespread usage for indexing. -# -# -# -# This group enables to establish a logical connection between previous -# processing steps or on-the-fly-performed indexing of the EBSD map. -# Typically these processing steps are performed with commercial software. -# Therefore, in many cases a results file from this indexing is often -# all that is communicated and saved. These are typically files in a format -# specific to the instrument and its configuration. -# -# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. -# -# -# -# -# Principal algorithm used for indexing. -# -# -# -# -# -# -# -# -# -# Details about the background correction applied to each Kikuchi pattern. -# -# -# -# -# Binning i.e. downsampling to each pattern. -# -# -# -# -# Specific parameter relevant only for certain algorithms used. -# -# -# -# -# Details for each phase used as a model with which the patterns were -# indexed. Instances of :ref:`NXunit_cell` in this group must -# have the group name prefixed with phase. The identifier in the name is an -# integer. Start counting from 1 because the value 0 is reserved for -# the special phase that is the null-model, the null phase also known -# as notIndexed. -# -# -# -# Spacing between the crystallographic planes that are defined via ``miller``. -# -# -# -# -# -# -# -# Relative intensity for the computed diffraction intensity (signal) for the -# plane. -# -# -# -# -# -# -# -# In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps -# this field stores how many scan points of the map were identified as matching best -# with this phase. -# -# -# -# -# How many reflectors for crystallographic planes are distinguished. -# -# -# -# -# Miller indices :math:`(hkl)[uvw]` of the planes. -# -# The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. -# Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. -# -# -# -# -# -# -# -# -# -# Which return value did the indexing algorithm yield for each scan point. -# -# * 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 :ref:`NXunit_cell`. -# -# In another example users may have skipped some scan points (not indexed -# them at all) or used differing numbers of phases for indexing different scan points. -# -# The cumulated of this array decodes how identifier_phase and matching_phase -# 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), -# identifier_phase has as many entries as scan points -# and matching_phase has also as many entries as scan points. -# -# -# -# -# -# -# -# The array phases_per_scan_point details how the identifier_phase -# and the matching_phase arrays have to be interpreted. -# -# For the example with a single phase identifier_phase 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 -# required) that a pattern matches eventually (not equally well) sufficiently -# significant with multiple patterns. This can especially happen in cases of -# pseudosymmetry and more frequently with an improperly calibrated system -# or false or inaccurate phase models. Having such field is especially relevant -# for recent dictionary- or artificial intelligence-based indexing methods to communicate -# the results in a model-agnostic way in combination with matching_phase. -# -# Depending on the phases_per_scan_point value, identifier_phase and -# matching_phase arrays represent a collection of concatenated tuples. -# These 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 phases_per_scan_point. -# -# -# -# -# -# -# -# One-dimensional array, pattern by pattern labelling the solutions found. -# The array phases_per_scan_point has to be specified because it details -# how the identifier_phase and the matching_phase arrays are interpreted. -# See documentation of identifier_phase for further details. -# -# -# -# -# -# -# -# Phase_matching is a descriptor for how well the solution matches or not. -# Examples can be confidence_index, mean_angular_deviation, or other. -# -# -# -# -# -# -# -# -# -# -# Calibrated centre positions of each scan point -# in the sample surface reference system. -# -# -# -# -# -# -# -# -# Fraction of successfully indexed patterns with a phase -# not the null-phase vs the number_of_scan_points. -# -# -# -# -# Number of scan points in the original mapping. -# -# -# -# -# -# An overview of the entire ROI. -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# -# -# -# -# Title of the default plot. -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# Descriptor values -# -# -# -# -# -# Calibrated coordinate along the y-axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated coordinate along the x-axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# From 02ba5c9e04f0b29b7d23a11233fc153f84c10104 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 14:07:37 +0200 Subject: [PATCH 19/57] Addressed and worked in phyy-nx review comments from https://github.com/nexusformat/definitions/pull/1423 starting with the inline comments, next step, address remaining comments that were made directly in the PR discussion --- contributed_definitions/NXem.nxdl.xml | 202 ++++++------------ .../NXevent_data_em.nxdl.xml | 9 +- contributed_definitions/nyaml/NXem.yaml | 142 ++++++------ .../nyaml/NXevent_data_em.yaml | 9 +- 4 files changed, 139 insertions(+), 223 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 20cdd45371..784d64102d 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -25,19 +25,13 @@ Application definition for normalized representation of electron microscopy research. - This application definition is a comprehensive example for a general description - with which to normalize specific (meta)data collected from the research field - of electron microscopy + This application definition is a comprehensive, general description for the + standardization of data and metadata collected using electron microscopy. NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena or to characterize materials with an electron microscope. + controlled electron beams are used to study electron-beam matter interactions, explore + physical mechanisms and phenomena, or to characterize materials with an electron microscope. - @@ -50,9 +44,8 @@ but for practical purposes currently is interpretable only by human to provide t - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. + A collection of all programs and libraries used to generate this NeXus file. + Ideally, this would enable a binary recreation from the input data. Examples include the name and version of the libraries used to write the instance. Ideally, the software which writes these NXprogram instances @@ -74,7 +67,11 @@ but for practical purposes currently is interpretable only by human to provide t - + + + A (globally) unique persistent identifier for referring to this experiment. + + Alias (short name) which scientists can use to refer to this experiment. @@ -86,9 +83,7 @@ but for practical purposes currently is interpretable only by human to provide t Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. + into the field. @@ -123,10 +118,9 @@ but for practical purposes currently is interpretable only by human to provide t Collection of serialized resources associated with the experiment. - - An example how to use this set is to document from which files in formatting - of technology partners, the (meta)data in an instance of NXem were filled with - during parsing to NeXus. + Examples of such resources are files which are formatted using proprietary + data models of technology partners as those generated by the control software + of the microscope during the instrument session. @@ -137,14 +131,6 @@ but for practical purposes currently is interpretable only by human to provide t Information about persons who performed or were involved in the microscope session or simulation run. - - Examples could be to put here the principle investigator who performed this - experiment or students who performed simulations to name but a few. - Adding multiple users if relevant is recommended. - - The protection of personal data by laws is in different stages of development - and strictness. Therefore, the existence of user data has not been made - required. @@ -203,16 +189,16 @@ but for practical purposes currently is interpretable only by human to provide t This is one of the most frequent use cases as during most sessions typically only a single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. - If multiple samples are investigated storing each of them in an own ENTRY group eventually will - demand an unnecessary duplication though of many details about the instrument. + If multiple samples are investigated storing each of them in their own ENTRY group eventually will + demand unnecessary duplication of instrument details. - This can be avoided by using another strategy how to store all samples and their results. + This can be avoided by using another strategy for storing samples and their results. Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., i.e. instances should use sample as a name prefix. - In this case though the collection of events demands to use identifier_sample to state clearly - for which of the samples loaded the (characterization) event was detected. + In this case the collection of events should use identifier_sample to state clearly for which + of the samples loaded the (characterization) event was detected. This concept is related to term `Specimen`_ of the EMglossary standard. @@ -235,13 +221,16 @@ but for practical purposes currently is interpretable only by human to provide t Ideally, (globally) unique persistent identifier which distinguishes this sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. + and especially the predecessor/origin from where that sample was cut off. An example of cutting off + is a steel sheet that is the parent sample from which a small portion was wire-eroded that + represents the sample that was then prepared for characterization with an electron microscope. + + The terms sample and specimen are here considered as exact synonyms. - This field must not be used for an alias for the sample! Instead, use name. + This field must not be used for an alias for the sample name. Instead, use name. In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single + the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single NXentry should be used for the characterization of a single specimen. Details about the specimen preparation should be stored in resources referring to identifier_parent. @@ -250,8 +239,8 @@ but for practical purposes currently is interpretable only by human to provide t - Identifier of the sample from which the sample was cut or the string *None*, - i.e. the parent to this sample. + Identifier of the sample from which the sample was cut off or the string *None*. + I.e. the parent to this sample. The purpose of this field is to support functionalities for tracking sample provenance in a research data management system. @@ -272,15 +261,15 @@ but for practical purposes currently is interpretable only by human to provide t required for material that is sensitive to the environment such as specimens that were charged with fast diffusing elements or short-lived radioactive tracers. - Additional time stamps prior to preparation_date should better be placed in resources - which describe but do not pollute the description here with prose. Resolving these - connected metadata is considered as within the responsibility of the - research data management system and not the a NeXus file. + Additional time stamps prior to preparation_date are better placed in resources which + describe but do not pollute the description here with prose. Resolving these + connected metadata is considered the responsibility of the research data management + system and not the a NeXus file. - An alias used to refer to the specimen to please readability for humans. + Specimen name @@ -315,9 +304,9 @@ but for practical purposes currently is interpretable only by human to provide t 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 a region-of-interest within connection to individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. + the usage of this field is discouraged and instead an instance of a + region-of-interest connected to individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details. @@ -424,14 +413,8 @@ but for practical purposes currently is interpretable only by human to provide t If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - + + @@ -440,12 +423,8 @@ but for practical purposes currently is interpretable only by human to provide t processing_reference_frame. - - - - - - + + @@ -454,12 +433,8 @@ but for practical purposes currently is interpretable only by human to provide t processing_reference_frame. - - - - - - + + @@ -468,12 +443,8 @@ but for practical purposes currently is interpretable only by human to provide t processing_reference_frame. - - - - - - + + @@ -499,14 +470,8 @@ but for practical purposes currently is interpretable only by human to provide t If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - + + @@ -515,12 +480,8 @@ but for practical purposes currently is interpretable only by human to provide t sample_reference_frame. - - - - - - + + @@ -529,12 +490,8 @@ but for practical purposes currently is interpretable only by human to provide t sample_reference_frame. - - - - - - + + @@ -543,12 +500,8 @@ but for practical purposes currently is interpretable only by human to provide t sample_reference_frame. - - - - - - + + @@ -576,14 +529,8 @@ but for practical purposes currently is interpretable only by human to provide t If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - + + @@ -592,12 +539,8 @@ but for practical purposes currently is interpretable only by human to provide t detector_reference_frame. - - - - - - + + @@ -606,12 +549,8 @@ but for practical purposes currently is interpretable only by human to provide t detector_reference_frame. - - - - - - + + @@ -620,22 +559,12 @@ but for practical purposes currently is interpretable only by human to provide t detector_reference_frame. - - - - - - + + - @@ -819,9 +748,6 @@ which components that microscope was built from--> - - Each NXimage instance must use only one image or stack instance. - @@ -996,9 +922,6 @@ which components that microscope was built from--> - - Each NXspectrum instance must use only one spectrum or stack instance. - @@ -1440,9 +1363,6 @@ specific way but then every user of this application definition is required to provide such information in this way!--> - - Each NXimage instance must use only one image or stack instance. - diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 75153913a6..cfe09bf08c 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -25,11 +25,10 @@ Base class to store state and (meta)data of events for electron microscopy. - To avoid that static instrument-related metadata need to be stored repetitively - (for each image and spectrum) the NXem application definitions splits the - storage of the (meta)data into those that typically do not change for a session - with the microscope and those which are often different for data that is collected - with the microscope. + Event-related (meta)data, typically measured datasets like images and spectra. + To avoid repetitively storing static instrument-related metadata, + the dynamic (meta)data that typically changes for each image and spectrum is split + from the static (meta)data. Which temporal granularity is adequate to log events depends on the situation and research question. Using a model which enables a collection of events offers diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 39c71aef26..b3a6353d4b 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -2,21 +2,14 @@ category: application doc: | Application definition for normalized representation of electron microscopy research. - This application definition is a comprehensive example for a general description - with which to normalize specific (meta)data collected from the research field - of electron microscopy + This application definition is a comprehensive, general description for the + standardization of data and metadata collected using electron microscopy. NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena or to characterize materials with an electron microscope. + controlled electron beams are used to study electron-beam matter interactions, explore + physical mechanisms and phenomena, or to characterize materials with an electron microscope. type: group NXem(NXobject): - - # docstrings should be organize as such a list of blocks: - # -| req: first part, concept definition, human-readable but such that one could take as is to define an concept in OWL - # -| opt: second part, comment, i.e. information that in an ideal world would be ideal if represented strongly semantic - # but for practical purposes currently is interpretable only by human to provide them further contextualization - # -| recommended: xref part ideally also as a list of triple (spec, term, url to uri) (NXentry): exists: ['min', '1', 'max', 'unbounded'] definition(NX_CHAR): @@ -28,9 +21,8 @@ NXem(NXobject): (NXprogram): exists: ['min', '0', 'max', 'unbounded'] doc: | - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. + A collection of all programs and libraries used to generate this NeXus file. + Ideally, this would enable a binary recreation from the input data. Examples include the name and version of the libraries used to write the instance. Ideally, the software which writes these NXprogram instances @@ -52,6 +44,8 @@ NXem(NXobject): identifier_experiment(NX_CHAR): exists: optional + doc: | + A (globally) unique persistent identifier for referring to this experiment. experiment_alias(NX_CHAR): exists: optional doc: | @@ -63,9 +57,7 @@ NXem(NXobject): Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. + into the field. start_time(NX_DATE_TIME): doc: | ISO 8601 time code with local time zone offset to UTC information included @@ -97,10 +89,9 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] doc: | Collection of serialized resources associated with the experiment. - - An example how to use this set is to document from which files in formatting - of technology partners, the (meta)data in an instance of NXem were filled with - during parsing to NeXus. + Examples of such resources are files which are formatted using proprietary + data models of technology partners as those generated by the control software + of the microscope during the instrument session. type(NX_CHAR): file_name(NX_CHAR): checksum(NX_CHAR): @@ -111,14 +102,6 @@ NXem(NXobject): doc: | Information about persons who performed or were involved in the microscope session or simulation run. - - Examples could be to put here the principle investigator who performed this - experiment or students who performed simulations to name but a few. - Adding multiple users if relevant is recommended. - - The protection of personal data by laws is in different stages of development - and strictness. Therefore, the existence of user data has not been made - required. identifierNAME(NX_CHAR): nameType: partial exists: recommended @@ -173,16 +156,16 @@ NXem(NXobject): This is one of the most frequent use cases as during most sessions typically only a single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. - | - If multiple samples are investigated storing each of them in an own ENTRY group eventually will - demand an unnecessary duplication though of many details about the instrument. + If multiple samples are investigated storing each of them in their own ENTRY group eventually will + demand unnecessary duplication of instrument details. - | - This can be avoided by using another strategy how to store all samples and their results. + This can be avoided by using another strategy for storing samples and their results. Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., i.e. instances should use sample as a name prefix. - | - In this case though the collection of events demands to use identifier_sample to state clearly - for which of the samples loaded the (characterization) event was detected. + In this case the collection of events should use identifier_sample to state clearly for which + of the samples loaded the (characterization) event was detected. - | xref: spec: EMglossary @@ -201,13 +184,16 @@ NXem(NXobject): exists: recommended doc: | Ideally, (globally) unique persistent identifier which distinguishes this sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. + and especially the predecessor/origin from where that sample was cut off. An example of cutting off + is a steel sheet that is the parent sample from which a small portion was wire-eroded that + represents the sample that was then prepared for characterization with an electron microscope. + + The terms sample and specimen are here considered as exact synonyms. - This field must not be used for an alias for the sample! Instead, use name. + This field must not be used for an alias for the sample name. Instead, use name. In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single + the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single NXentry should be used for the characterization of a single specimen. Details about the specimen preparation should be stored in resources referring to identifier_parent. @@ -215,8 +201,8 @@ NXem(NXobject): identifier_parent(NX_CHAR): exists: recommended doc: | - Identifier of the sample from which the sample was cut or the string *None*, - i.e. the parent to this sample. + Identifier of the sample from which the sample was cut off or the string *None*. + I.e. the parent to this sample. The purpose of this field is to support functionalities for tracking sample provenance in a research data management system. @@ -235,14 +221,14 @@ NXem(NXobject): required for material that is sensitive to the environment such as specimens that were charged with fast diffusing elements or short-lived radioactive tracers. - Additional time stamps prior to preparation_date should better be placed in resources - which describe but do not pollute the description here with prose. Resolving these - connected metadata is considered as within the responsibility of the - research data management system and not the a NeXus file. + Additional time stamps prior to preparation_date are better placed in resources which + describe but do not pollute the description here with prose. Resolving these + connected metadata is considered the responsibility of the research data management + system and not the a NeXus file. name(NX_CHAR): exists: recommended doc: | - An alias used to refer to the specimen to please readability for humans. + Specimen name atom_types(NX_CHAR): doc: | List of comma-separated elements from the periodic table that are contained in the sample. @@ -275,9 +261,9 @@ NXem(NXobject): 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 a region-of-interest within connection to individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. + the usage of this field is discouraged and instead an instance of a + region-of-interest connected to individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details. description(NX_CHAR): exists: optional doc: | @@ -347,25 +333,33 @@ NXem(NXobject): of the reference frame. If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + enumeration: + open: true + values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the processing_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the processing_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the processing_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): exists: recommended depends_on(NX_CHAR): @@ -388,25 +382,33 @@ NXem(NXobject): of the reference frame. If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + enumeration: + open: true + values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the sample_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the sample_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the sample_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): nameType: partial exists: ['min', '0', 'max', 'unbounded'] @@ -431,33 +433,35 @@ NXem(NXobject): along respective base vector direction of the reference frame. If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + enumeration: + open: true + values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the detector_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the detector_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the detector_reference_frame. - enumeration: [north, east, south, west, in, out] + enumeration: + open: true + values: [north, east, south, west, in, out] measurement(NXem_measurement): exists: optional - # the choice if a concept filling content in NXfabrication is recommended or optional - # was made such that all for all those components which are typically add-ons in a - # microscope it is more likely that individuals will have bought different third-party tools - # and therefore, for these typically more optional add-ons NXfabrication is recommended - # for others commercial microscopes often come with model-specific predefined parts - # hence using optional is sufficient instrument(NXinstrument_em): name(NX_CHAR): exists: recommended @@ -700,8 +704,6 @@ NXem(NXobject): imageID(NXimage): exists: ['min', '0', 'max', 'unbounded'] nameType: partial - doc: | - Each NXimage instance must use only one image or stack instance. (NXprocess): exists: recommended input(NXnote): @@ -868,8 +870,6 @@ NXem(NXobject): spectrumID(NXspectrum): exists: ['min', '0', 'max', 'unbounded'] nameType: partial - doc: | - Each NXspectrum instance must use only one spectrum or stack instance. (NXprocess): exists: recommended input(NXnote): @@ -1334,8 +1334,6 @@ NXem(NXobject): imageID(NXimage): nameType: partial exists: ['min', '1', 'max', 'unbounded'] - doc: | - Each NXimage instance must use only one image or stack instance. imaging_mode(NX_CHAR): (NXmicrostructure): exists: optional diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index adb792840a..cfd4b66f6b 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -2,11 +2,10 @@ category: base doc: | Base class to store state and (meta)data of events for electron microscopy. - To avoid that static instrument-related metadata need to be stored repetitively - (for each image and spectrum) the NXem application definitions splits the - storage of the (meta)data into those that typically do not change for a session - with the microscope and those which are often different for data that is collected - with the microscope. + Event-related (meta)data, typically measured datasets like images and spectra. + To avoid repetitively storing static instrument-related metadata, + the dynamic (meta)data that typically changes for each image and spectrum is split + from the static (meta)data. Which temporal granularity is adequate to log events depends on the situation and research question. Using a model which enables a collection of events offers From 2337fa8e1cb0606e21a3db80859fff20e2669fee Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 19:10:00 +0200 Subject: [PATCH 20/57] Work on the EM part of the proposal, i) next step split groups in NXcs_computer, ii) review remaining large EM base classes --- contributed_definitions/NXaberration.nxdl.xml | 35 ++- contributed_definitions/NXatom.nxdl.xml | 31 ++- contributed_definitions/NXcircuit.nxdl.xml | 43 +-- .../NXcorrector_cs.nxdl.xml | 64 +---- .../NXcs_computer.nxdl.xml | 20 +- .../NXebeam_column.nxdl.xml | 20 +- contributed_definitions/NXem.nxdl.xml | 126 ++++++--- .../NXem_measurement.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 52 ++-- .../NXibeam_column.nxdl.xml | 100 +++---- contributed_definitions/NXimage.nxdl.xml | 12 +- .../NXinteraction_volume_em.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 118 +++----- .../nyaml/NXaberration.yaml | 9 +- contributed_definitions/nyaml/NXatom.yaml | 24 +- contributed_definitions/nyaml/NXcircuit.yaml | 42 +-- .../nyaml/NXcorrector_cs.yaml | 70 ++--- .../nyaml/NXcs_computer.yaml | 24 +- .../nyaml/NXebeam_column.yaml | 258 +----------------- contributed_definitions/nyaml/NXem.yaml | 48 ++-- .../nyaml/NXem_measurement.yaml | 5 +- .../nyaml/NXevent_data_em.yaml | 52 ++-- .../nyaml/NXibeam_column.yaml | 157 +---------- contributed_definitions/nyaml/NXimage.yaml | 12 +- .../nyaml/NXinteraction_volume_em.yaml | 2 +- contributed_definitions/nyaml/NXion.yaml | 44 +-- 26 files changed, 453 insertions(+), 921 deletions(-) diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index c2fb7388f0..2c3c5f3460 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -23,47 +23,54 @@ --> - Quantified aberration coefficient in an aberration_model. + Quantified aberration coefficient in an aberration_model. + + For an introduction in the aberrations in electron microscopy + see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and + `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. + Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. - Magnitude of the aberration + Magnitude of the aberration - Uncertainty of the magnitude of the aberration + Uncertainty of the magnitude of the aberration - Free-text description how magnitude_errors was quantified - e.g. via the 95% confidence interval, variance, standard deviation, - using which algorithm or statistical model. + Free-text description how magnitude_errors was quantified + e.g. via the 95% confidence interval, variance, standard deviation, + using which algorithm or statistical model. - Time elapsed since the last measurement. + Time elapsed since the last measurement. - 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. + 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. - Given name to this aberration. + Given name to this aberration. - Alias also used to name and refer to this specific type of aberration. + Alias to name or refer to this specific type of aberration. diff --git a/contributed_definitions/NXatom.nxdl.xml b/contributed_definitions/NXatom.nxdl.xml index 8045cd121f..698d8c469b 100644 --- a/contributed_definitions/NXatom.nxdl.xml +++ b/contributed_definitions/NXatom.nxdl.xml @@ -22,21 +22,35 @@ # For further information, see http://www.nexusformat.org --> + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of atom positions. + + + + + Dimensionality + + + Base class for documenting a set of atoms. - Atoms in the set may be bonded. - The set may have a net charge to represent - an ion. Ions can be molecular ions. + Atoms in the set may be bonded. The set may have + a net charge to represent an ion. + Ions can be molecular ions. Given name for the set. This field could for example be used in the research field - of atom probe tomography for storing a standardized - human-readable name of the element or (molecular) ion - like such as Al +++ or 12C +. + of atom probe tomography to store a standardized human-readable + name of the element or (molecular) ion like such as Al +++ or 12C +. @@ -78,7 +92,6 @@ that is unique as a some cut-off criterion is required. - Index for each atom at locations as detailed by position. @@ -92,8 +105,8 @@ Nuclide information for each atom at locations as detailed by position. - One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information efficiently - is via hashing with the following formula + One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information + efficiently is via hashing with the following formula :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` diff --git a/contributed_definitions/NXcircuit.nxdl.xml b/contributed_definitions/NXcircuit.nxdl.xml index 8bd88df94d..5159cce2f9 100644 --- a/contributed_definitions/NXcircuit.nxdl.xml +++ b/contributed_definitions/NXcircuit.nxdl.xml @@ -29,43 +29,43 @@ - number of channels of the circuit board. + Number of channels of the circuit board. - Application definition for circuit devices. + Base class for documenting circuit devices. - Electronic circuits are hardware components connecting several electronic components to achieve + Electronic circuits are hardware components that connect several electronic components to achieve specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. - Hardware where the circuit is implanted; includes information about the hardware manufacturers and - type (e.g. part number) + Hardware where the circuit is implanted; includes information about the + hardware manufacturers and type (e.g. part number) All the elements below may be single numbers of an array of values with length N_channel describing multiple input and output channels. - + List of components used in the circuit, e.g., resistors, capacitors, transistors or any other complex components. - + Description of how components are interconnected, including connection points and wiring. - + Details of the power source for the circuit, including voltage and current ratings. - + Type of signal (input signal) the circuit is designed to handle, e.g., analog, digital, mixed-signal. @@ -74,9 +74,14 @@ - The operating frequency of the circuit, see also bandwidth below, which is possibly - centered around this frequency. However, not necessarily (e.g. running a 100 kHz bandwidth - amplifier at low, audio frequencies 1 - 20,000 Hz) + The operating frequency of the circuit, see also bandwidth, which is possibly + but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth + amplifier at low, audio frequencies 1 - 20,000 Hz). + + + + + The bandwidth of the frequency response of the circuit. @@ -92,18 +97,14 @@ - Gain of the circuit, if applicable, usually all instruments have a gain which might be - important or not. + Gain of the circuit, if applicable, usually all instruments have a gain + which might be important or not. - RMS noise level (in current or voltage) in the circuit in voltage or current. - - - - - The bandwidth of the frequency response of the circuit. + Root-mean-square (RMS) noise level (in current or voltage) + in the circuit in voltage or current. @@ -136,7 +137,7 @@ Power consumption of the circuit per unit time. - + Status indicators for the circuit, e.g., LEDs, display readouts. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 3269469b39..6ffc2af1d1 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -21,8 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -40,12 +38,14 @@ https://doi.org/10.1017/9781316337455.022--> Different technology partners use different conventions and models for quantifying the aberration coefficients. - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details that are specific for the technology partner - and microscope. Most technical details are proprietary knowledge. + Correctors in an electron microscope are composed of multiple lenses + and multipole stigmators. Their technical details are specific for the + technology partner as well as microscope. Most technical details are + proprietary knowledge. - If one component corrects for multiple types of aberrations (like it is the case reported - here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this design: + If one component corrects for multiple types of aberrations (like it is the case + reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this + design when using corrector and monochromator in an application definition: * Use :ref:`NXcorrector_cs` for spherical aberration * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration @@ -57,9 +57,9 @@ https://doi.org/10.1017/9781316337455.022--> Was the corrector used? - + - Specific information about the alignment procedure that is a process during which + Specific information about the alignment procedure. This is a process during which the corrector is configured to enable calibrated usage of the instrument. This :ref:`NXprocess` group should also be used when one describes in a computer @@ -76,7 +76,8 @@ https://doi.org/10.1017/9781316337455.022--> The outer tilt angle of the beam in tableau acquisition. TODO: The relevant axes which span the tilt_angle need a - cleaner description. + cleaner description. Suggestions from the community are + welcome here for guiding an improvement of this base class. @@ -99,14 +100,14 @@ https://doi.org/10.1017/9781316337455.022--> - + Image(s) taken during the alignment procedure - Convention used for storing measured or estimated aberrations (for each image or final) + Convention used for storing measured or estimated aberrations (for each or the final image) via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) @@ -162,45 +163,6 @@ https://doi.org/10.1017/9781316337455.022--> - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 60c2873035..3910a494ea 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -34,7 +34,12 @@ 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 @@ -47,7 +52,7 @@ - Ideally a (globally) unique persistent identifier of the computer, i.e. + A globally unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. @@ -60,10 +65,11 @@ Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. + with a single CPU; describe using one instance of NXcircuit. + A dual-socket server; describe using two instances of NXcircuit. + A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. @@ -94,7 +100,7 @@ Qualifier for the type of random access memory. - + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 9ab8d42264..897d934f68 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -3,7 +3,7 @@ - - + + - Base class for a set of components equipping an instrument with FIB capabilities. - - Focused-ion-beam (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. The beam is intense enough and with sufficient ion momentum to - remove material in a controlled 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 the definition of 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>`_ + Base class for a set of components equipping an instrument with FIB capabilities. + + Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped + with sufficient ion having sufficient momentum to remove material in a controlled + manner. + + The fact that an electron microscope with FIB capabilities achieves these functionalities + via a second component (aka the ion gun) that has its own relevant control circuits, + focusing lenses, and other components, warrants the definition of 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. + The source which creates the ion beam. - Given name/alias for the ion gun. + 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. + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. @@ -72,43 +74,43 @@ - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. + 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+. + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. - Average/nominal flux + Average/nominal flux - Average/nominal brightness + Average/nominal brightness - 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. - To be defined more specifically. Community suggestions are welcome. + To be defined more specifically. Community suggestions are welcome. @@ -116,19 +118,19 @@ NEW ISSUE: (at which location?).--> - + - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - :ref:`NXtransformations` should be used to specify the location or position - at which details about the ion beam are probed. + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + :ref:`NXtransformations` should be used to specify the location or position + at which details about the ion beam are probed. - + diff --git a/contributed_definitions/NXimage.nxdl.xml b/contributed_definitions/NXimage.nxdl.xml index e44f7f2941..96be44fea1 100644 --- a/contributed_definitions/NXimage.nxdl.xml +++ b/contributed_definitions/NXimage.nxdl.xml @@ -46,7 +46,7 @@ - Base class for reporting a set of images. + Base class for reporting a set of images representing specializations of NXdata. The most commonly used scanning methods are supported. That is one-, two-, three-dimensional ROIs discretized using regular Euclidean tilings. @@ -63,12 +63,10 @@ Point coordinates identify the location of the barycenter. For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode - images in reciprocal (frequency) space. FFT libraries are used for implementing the key functionalities of - these mathematical operations. - + Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal + (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations + Details can be found in the respective sections of the typical FFT libraries documentations: * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ @@ -83,7 +81,7 @@ the number of images which are combined into collections is not necessarily the same for each collection. The NXimage base class addresses this logical distinction through the notation of indices_image and indices_group concepts. - That is indices_image are always counting from offset in increments of one. + That is indices_image are always counting from offset in increments of one as each image is its own entity. By contrast, a group may contain no, or several images. Consequently, indices_group are not required to be contiguous. diff --git a/contributed_definitions/NXinteraction_volume_em.nxdl.xml b/contributed_definitions/NXinteraction_volume_em.nxdl.xml index 129c785080..e7f1652e80 100644 --- a/contributed_definitions/NXinteraction_volume_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_volume_em.nxdl.xml @@ -23,7 +23,7 @@ --> - Base class to group data and descriptions of the volume of interaction for particle-matter interaction. + Base class to describe the volume of interaction for particle-matter interaction. Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam interaction simulations can be used to qualify and (or) quantify the shape of diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 356c8087d8..779cea7584 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -21,34 +21,34 @@ # # For further information, see http://www.nexusformat.org --> - + - 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 atoms/isotopes allowed per (molecular) ion (fragment). + Maximum number of atoms/isotopes allowed 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. - Base class for documenting the set of atoms of a (molecular) ion. + Base class for documenting the set of atoms of a (molecular) ion. - A unique identifier whereby such an ion can be referred to - via the service offered as described in id_type. + A unique identifier whereby such an ion can be referred to + via the service offered as described in id_type. - How can the identifier be resolved? + How can the identifier be resolved? @@ -56,20 +56,20 @@ - 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. - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + Vector of nuclide hash values. + + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + encode the number of protons :math:`Z` and the number of neutrons :math:`N` + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + + The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ @@ -77,78 +77,32 @@ - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no + isotope-specific information about the element encoded is relevant. + The second row specifies the number of protons :math:`Z` or 0. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a value pair (14, 6) as one row of the table. + + Therefore, this notation is the typical superscribed nuclide mass number + and subscripted number of protons element notation e.g. :math:`^{14}C`. + The array is stored matching the order of nuclide_hash. - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. + Associated lower (mqmin) and upper (mqmax) bounds of the + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml index 43792ab8d7..80cfeecc18 100644 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ b/contributed_definitions/nyaml/NXaberration.yaml @@ -1,6 +1,13 @@ category: base doc: | Quantified aberration coefficient in an aberration_model. + + For an introduction in the aberrations in electron microscopy + see `R. Dunin-Borkowski et al. `_ and + `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. + Conversion tables are also summarized by `Y. Liao `_ an introduction. type: group NXaberration(NXobject): magnitude(NX_NUMBER): @@ -33,7 +40,7 @@ NXaberration(NXobject): Given name to this aberration. alias(NX_CHAR): doc: | - Alias also used to name and refer to this specific type of aberration. + Alias to name or refer to this specific type of aberration. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 0886da2916670a78790d1d643a4dcd05706da7f69d5605ad5456265640041c73 diff --git a/contributed_definitions/nyaml/NXatom.yaml b/contributed_definitions/nyaml/NXatom.yaml index fa28d06146..da49385bb7 100644 --- a/contributed_definitions/nyaml/NXatom.yaml +++ b/contributed_definitions/nyaml/NXatom.yaml @@ -2,9 +2,16 @@ category: base doc: | Base class for documenting a set of atoms. - Atoms in the set may be bonded. - The set may have a net charge to represent - an ion. Ions can be molecular ions. + Atoms in the set may be bonded. The set may have + a net charge to represent an ion. + Ions can be molecular ions. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_pos: | + Number of atom positions. + d: | + Dimensionality type: group NXatom(NXobject): name(NX_CHAR): @@ -12,9 +19,8 @@ NXatom(NXobject): Given name for the set. This field could for example be used in the research field - of atom probe tomography for storing a standardized - human-readable name of the element or (molecular) ion - like such as Al +++ or 12C +. + of atom probe tomography to store a standardized human-readable + name of the element or (molecular) ion like such as Al +++ or 12C +. identifier_chemical(NX_CHAR): doc: | Identifier used to refer to if the set of atoms represents a substance. @@ -47,8 +53,6 @@ NXatom(NXobject): Neither individual atoms nor a set of cluster of these have a volume that is unique as a some cut-off criterion is required. - - # indices(NX_CHAR): doc: | Index for each atom at locations as detailed by position. @@ -61,8 +65,8 @@ NXatom(NXobject): doc: | Nuclide information for each atom at locations as detailed by position. - One `approach `_ for storing nuclide information efficiently - is via hashing with the following formula + One `approach `_ for storing nuclide information + efficiently is via hashing with the following formula :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 528df8db00..10531ce484 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -1,36 +1,36 @@ category: base doc: | - Application definition for circuit devices. + Base class for documenting circuit devices. - Electronic circuits are hardware components connecting several electronic components to achieve + Electronic circuits are hardware components that connect several electronic components to achieve specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. symbols: doc: | Constant to be used in the definition: the number of channels of the circuit board. N_channel: | - number of channels of the circuit board. + Number of channels of the circuit board. type: group NXcircuit(NXcomponent): hardware(NXfabrication): doc: | - Hardware where the circuit is implanted; includes information about the hardware manufacturers and - type (e.g. part number) + Hardware where the circuit is implanted; includes information about the + hardware manufacturers and type (e.g. part number) All the elements below may be single numbers of an array of values with length N_channel describing multiple input and output channels. - components: + components(NX_CHAR): doc: | List of components used in the circuit, e.g., resistors, capacitors, transistors or any other complex components. - connections: + connections(NX_CHAR): doc: | Description of how components are interconnected, including connection points and wiring. - power_source: + power_source(NX_CHAR): doc: | Details of the power source for the circuit, including voltage and current ratings. - signal_type: + signal_type(NX_CHAR): doc: | Type of signal (input signal) the circuit is designed to handle, e.g., analog, digital, mixed-signal. @@ -39,10 +39,13 @@ NXcircuit(NXcomponent): operating_frequency(NX_NUMBER): unit: NX_FREQUENCY doc: | - The operating frequency of the circuit, see also bandwidth below, which is possibly - centered around this frequency. However, not necessarily (e.g. running a 100 kHz bandwidth - amplifier at low, audio frequencies 1 - 20,000 Hz) - + The operating frequency of the circuit, see also bandwidth, which is possibly + but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth + amplifier at low, audio frequencies 1 - 20,000 Hz). + bandwidth(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The bandwidth of the frequency response of the circuit. # we may need an NX_RESISTANCE defined input_impedance(NX_NUMBER): unit: NX_ANY @@ -55,16 +58,13 @@ NXcircuit(NXcomponent): gain(NX_NUMBER): unit: NX_UNITLESS doc: | - Gain of the circuit, if applicable, usually all instruments have a gain which might be - important or not. + Gain of the circuit, if applicable, usually all instruments have a gain + which might be important or not. noise_level(NX_NUMBER): unit: NX_ANY doc: | - RMS noise level (in current or voltage) in the circuit in voltage or current. - bandwidth(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The bandwidth of the frequency response of the circuit. + Root-mean-square (RMS) noise level (in current or voltage) + in the circuit in voltage or current. temperature_range(NX_NUMBER): unit: NX_ANY doc: | @@ -87,7 +87,7 @@ NXcircuit(NXcomponent): unit: NX_ANY doc: | Power consumption of the circuit per unit time. - status_indicators: + status_indicators(NX_CHAR): doc: | Status indicators for the circuit, e.g., LEDs, display readouts. protection_features(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 145a915967..59e26c23eb 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -5,34 +5,34 @@ doc: | Different technology partners use different conventions and models for quantifying the aberration coefficients. - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details that are specific for the technology partner - and microscope. Most technical details are proprietary knowledge. + Correctors in an electron microscope are composed of multiple lenses + and multipole stigmators. Their technical details are specific for the + technology partner as well as microscope. Most technical details are + proprietary knowledge. - If one component corrects for multiple types of aberrations (like it is the case reported - here `CEOS `_) follow this design: + If one component corrects for multiple types of aberrations (like it is the case + reported here `CEOS `_) follow this + design when using corrector and monochromator in an application definition: * Use :ref:`NXcorrector_cs` for spherical aberration * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration + symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_img: | Number of images taken, at least one. - -# https://doi.org/10.1017/9781316337455.022 type: group NXcorrector_cs(NXcomponent): - # user perspective applied(NX_BOOLEAN): doc: | Was the corrector used? - TABLEAU(NXprocess): - nameType: any + tableauID(NXprocess): + nameType: partial doc: | - Specific information about the alignment procedure that is a process during which + Specific information about the alignment procedure. This is a process during which the corrector is configured to enable calibrated usage of the instrument. This :ref:`NXprocess` group should also be used when one describes in a computer @@ -47,7 +47,8 @@ NXcorrector_cs(NXcomponent): The outer tilt angle of the beam in tableau acquisition. TODO: The relevant axes which span the tilt_angle need a - cleaner description. + cleaner description. Suggestions from the community are + welcome here for guiding an improvement of this base class. dimensions: rank: 1 dim: (n_img,) @@ -66,12 +67,13 @@ NXcorrector_cs(NXcomponent): dimensions: rank: 1 dim: (n_img,) - (NXimage): + imageID(NXimage): + nameType: partial doc: | Image(s) taken during the alignment procedure model(NX_CHAR): doc: | - Convention used for storing measured or estimated aberrations (for each image or final) + Convention used for storing measured or estimated aberrations (for each or the final image) via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) @@ -124,46 +126,6 @@ NXcorrector_cs(NXcomponent): c_5_4_b(NXaberration): c_5_6_a(NXaberration): c_5_6_b(NXaberration): - - # 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 transferfunction: ctf = e^(-i*Xi(g)) in Fourier space - # aberration function: - # Xi(g) = 2*pi/lambda{ 1/2 * (lambda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - # +1/3 * (lambda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - # +1/4 * (lambda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - # +1/f * (lambda*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 occur but is not common. - # A separate 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. - # technical design perspective (NXlens_em): (NXaperture): (NXdeflector): diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 9ce20bba13..29a246a7c9 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -9,7 +9,10 @@ NXcs_computer(NXobject): operating_system(NX_CHAR): doc: | Name of the operating system, e.g. Windows, Linux, Mac, Android. - \@version: + enumeration: + open_enum: true + items: [windows, unix, macintosh] + \@version(NX_CHAR): doc: | Version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build @@ -20,7 +23,7 @@ NXcs_computer(NXobject): # difference e.g. in Win11 between hardware ID, UUID, and device ID uuid(NX_CHAR): doc: | - Ideally a (globally) unique persistent identifier of the computer, i.e. + 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 @@ -31,16 +34,17 @@ NXcs_computer(NXobject): (NXcircuit): doc: | Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. + with a single CPU; describe using one instance of NXcircuit. + A dual-socket server; describe using two instances of NXcircuit. + A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. type(NX_CHAR): - doc: | - General type of the processing unit enumeration: open_enum: true items: [cpu, gpu, fpga] + doc: | + General type of the processing unit name(NX_CHAR): doc: | Given name @@ -53,7 +57,9 @@ NXcs_computer(NXobject): type(NX_CHAR): doc: | Qualifier for the type of random access memory. - enumeration: [ddr4, ddr5] + enumeration: + open_enum: true + items: [ddr4, ddr5] max_physical_capacity(NX_POSINT): unit: NX_ANY doc: | diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index d1fc2142af..8e412aef81 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -4,23 +4,23 @@ doc: | The idea behind defining NXebeam_column as an own base class vs. adding these concepts in NXinstrument_em is that the electron beam generating component - might be worthwhile to use in other experiments also. + might be worthwhile to use also in other types of experiments. type: group NXebeam_column(NXcomponent): operation_mode(NX_CHAR): doc: | Tech-partner, microscope-, and control-software-specific name of the - specific operation mode how the ebeam_column and its components are controlled - to achieve specific illumination conditions. + specific operation mode how the ebeam_column and its components are + controlled to achieve specific illumination conditions. In many cases the users of an instrument do not or can not be expected to know - all intricate spatiotemporal dynamics of their hardware. Instead, they rely of + all intricate spatiotemporal dynamics of their hardware. Instead, they rely on assumptions that the instrument, its control software, and components work as expected to focus on their research questions. For these cases, having a place for documenting the operation_mode is useful in as much as at least some constraints on how the illumination conditions were - get documented. + is documented. electron_source(NXsource): doc: - | @@ -146,13 +146,12 @@ NXebeam_column(NXcomponent): 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 users. - BIPRISM(NXcomponent): - nameType: any + biprismID(NXcomponent): + nameType: partial doc: | Electron biprism as it is used e.g. for electron holography. - (NXfabrication): - PHASEPLATE(NXcomponent): - nameType: any + phaseplateID(NXcomponent): + nameType: partial doc: | Device that causes a change in the phase of an electron wave. @@ -164,8 +163,6 @@ NXebeam_column(NXcomponent): enumeration: open_enum: true items: [thin_film, electrostatic] - (NXfabrication): - (NXcomponent): (NXsensor): (NXactuator): (NXbeam): @@ -181,239 +178,4 @@ NXebeam_column(NXcomponent): spec: EMglossary term: Electron Beam url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bad370dd2f91335848079fa63885c75bcb1b443ee4c7fb9b45c4a4f32c8d9159 -# -# -# -# -# -# Base class for a set of components providing a controllable electron beam. -# -# The idea behind defining NXebeam_column as an own base class vs. adding these -# concepts in NXinstrument_em is that the electron beam generating component -# might be worthwhile to use in other experiments also. -# -# -# -# Tech-partner, microscope-, and control-software-specific name of the -# specific operation mode how the ebeam_column and its components are controlled -# to achieve specific illumination conditions. -# -# In many cases the users of an instrument do not or can not be expected to know -# all intricate spatiotemporal dynamics of their hardware. Instead, they rely of -# assumptions that the instrument, its control software, and components work as -# expected to focus on their research questions. -# -# For these cases, having a place for documenting the operation_mode is useful -# in as much as at least some constraints on how the illumination conditions were -# get documented. -# -# -# -# -# A physical part of an electron or ion microscope from which -# the particles that form the beam are emitted. -# -# The hardware for an electron source in an electron microscope -# may contain several components which affect the beam path. -# -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 -# -# -# -# The potential difference between anode and cathode. -# -# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. -# -# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 -# -# -# -# -# Voltage which is used to create an electric field that draws particles from -# the source. -# -# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. -# -# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which is released from the source. -# -# This concept is related to term `Emission Current`_ of the EMglossary standard. -# -# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which flows through the source. -# -# This concept is related to term `Filament Current`_ of the EMglossary standard. -# -# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 -# -# -# -# -# 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. -# -# -# -# -# -# How long has the source been in operation. -# -# -# -# -# -# -# -# -# Device to improve energy resolution or chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ -# -# -# -# -# Qualitative type of the component. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Was the corrector used? -# -# -# -# -# -# Energy dispersion in e.g. µm/eV. -# -# -# -# -# Corresponding voltage for that energy dispersion. -# -# -# -# -# -# -# Component that reshapes an ellipse-shaped electron beam into a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. -# -# -# -# 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 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 users. -# -# -# -# -# -# Electron biprism as it is used e.g. for electron holography. -# -# -# -# -# -# Device that causes a change in the phase of an electron wave. -# -# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ -# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ -# -# -# -# Qualitative type -# -# -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the electron beam at a given location. -# -# :ref:`NXtransformations` should be used to specify the location -# or the position at which details about the beam were probed. -# -# This concept is related to term `Electron Beam`_ of the EMglossary standard. -# -# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 -# -# -# + (NXcomponent): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b3a6353d4b..da6ba1fe7d 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -334,32 +334,32 @@ NXem(NXobject): If any of these assumptions is not met, the user is required to explicitly state this. enumeration: - open: true - values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the processing_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the processing_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the processing_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): exists: recommended depends_on(NX_CHAR): @@ -383,32 +383,32 @@ NXem(NXobject): If any of these assumptions is not met, the user is required to explicitly state this. enumeration: - open: true - values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the sample_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the sample_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the sample_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): nameType: partial exists: ['min', '0', 'max', 'unbounded'] @@ -434,32 +434,32 @@ NXem(NXobject): If any of these assumptions is not met, the user is required to explicitly state this. enumeration: - open: true - values: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing x-axis base vector of the detector_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing y-axis base vector of the detector_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | Direction of the positively pointing z-axis base vector of the detector_reference_frame. enumeration: - open: true - values: [north, east, south, west, in, out] + open_enum: true + items: [north, east, south, west, in, out] measurement(NXem_measurement): exists: optional instrument(NXinstrument_em): diff --git a/contributed_definitions/nyaml/NXem_measurement.yaml b/contributed_definitions/nyaml/NXem_measurement.yaml index cb85304bbf..b759d7163d 100644 --- a/contributed_definitions/nyaml/NXem_measurement.yaml +++ b/contributed_definitions/nyaml/NXem_measurement.yaml @@ -3,5 +3,6 @@ doc: | Base class for documenting a measurement with an electron microscope. type: group NXem_measurement(NXobject): - (NXinstrument_em): - (NXevent_data_em): + instrument(NXinstrument_em): + eventID(NXevent_data_em): + nameType: partial diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index cfd4b66f6b..596a0ee8e1 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -4,8 +4,8 @@ doc: | Event-related (meta)data, typically measured datasets like images and spectra. To avoid repetitively storing static instrument-related metadata, - the dynamic (meta)data that typically changes for each image and spectrum is split - from the static (meta)data. + the dynamic (meta)data that typically changes for each image and spectrum + is split from the static (meta)data. Which temporal granularity is adequate to log events depends on the situation and research question. Using a model which enables a collection of events offers @@ -23,15 +23,15 @@ doc: | In all these use cases it is useful to have a mechanism whereby time-dependent data of the instrument state can be stored and documented in an representation - that facilitates interoperability. + that facilitates interoperability. This is the idea behind this base class. :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly whatever is considered a time interval during which the instrument is - considered stable enough for allowing any working on tasks with the microscope. + considered stable enough for allowing any working on tasks with it. Examples of such tasks are the collecting of data (images and spectra) or the calibrating the instrument or individual of its components. Users may wish to take - only a single scan or image and complete their microscope session thereafter. - Alternatively, users are working for much longer time at the microscope, + only a single scan or image and complete their session thereafter. + Alternatively, users are working for much longer time at the instrument, perform recalibrations in between and take several scans (of different ROIs on the specimen), or they explore the state of the microscope for service or maintenance tasks. @@ -41,14 +41,7 @@ doc: | * Firstly, via a header section whose purpose is to contextualize and identify the event instance in time. * Secondly, via a data and metadata section where individual data - collections can be stored in a standardized representation. - - The idea of the first section, the event-based em_lab, is to document the - state of the microscope as it was found during the event. The idea of the other, - the :ref:`NXem` application-definition-based em_lab(NXinstrument) section is to - keep all those data that are static in the sense that they remain the same - across multiple :ref:`NXevent_data_em` instances. - This reduces the need for having many copies of the same metadata. + collections can be stored in a standardized representation. We are aware of the fact that given the variety how an electron microscope is used, there is a need for a flexible and adaptive documentation system. @@ -67,29 +60,28 @@ doc: | or a stack of spectra. Having to deal with instabilities is a common theme in electron microscopy practice. Numerical protocols can be used during data post-processing to correct for some of the instabilities. - A few exemplar references to provide an overview on the subject is - available in the literature: + A few exemplar references provide an overview on the subject: * `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, + the experiment (digital twin), 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 and ions, - or detector noise models. This warrants to document the time-dependent - details of individual components of the microscope - as is implemented in :ref:`NXevent_data_em`. + beam shape functions, trajectories of groups of electrons and ions, or detector noise models. + This also warrants to document the time-dependent details of individual components + of the microscope via the here implemented class :ref:`NXevent_data_em`. type: group NXevent_data_em(NXobject): 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 + when the snapshot time interval started. + + If users wish 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: | @@ -102,8 +94,7 @@ NXevent_data_em(NXobject): identifier_sample(NX_CHAR): unit: NX_UNITLESS doc: | - The name of the sample instance under NXem/ENTRY/SAMPLE to resolve - ambiguities that are explained in the docstring of NXem/ENTRY/SAMPLE. + The name of the sample to resolve ambiguities. type(NX_CHAR): doc: | Which specific event/measurement type. Examples are: @@ -127,11 +118,8 @@ NXevent_data_em(NXobject): about the event for which there is at the moment no other place. In the long run such free-text field description should be avoided as - they are difficult to machine-interpret. Instead, reference should be given - to refactoring these descriptions into structured metadata. - The reason why in this base class the field event_type is nonetheless kept - is to offer a place whereby practically users may enter data for - follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. + it is difficult to machine-interpret. Instead, an enumeration should + be used. (NXuser): (NXinstrument_em): (NXimage): diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index cf7cd8cb1f..d74b39815d 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -5,13 +5,14 @@ doc: | Focused-ion-beam (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. The beam is intense enough and with sufficient ion momentum to - remove material in a controlled manner. + intensity. The beam is controlled such that it is intense, focused, and equipped + with sufficient ion having sufficient momentum to remove material in a controlled + 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 the definition of an own base class to group these - components and distinguish them from the lenses and components for creating + The fact that an electron microscope with FIB capabilities achieves these functionalities + via a second component (aka the ion gun) that has its own relevant control circuits, + focusing lenses, and other components, warrants the definition of 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 @@ -21,7 +22,7 @@ doc: | * `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. type: group @@ -77,9 +78,9 @@ NXibeam_column(NXcomponent): (NXlens_em): (NXaperture): (NXmonochromator): - (NXcomponent): (NXsensor): (NXactuator): + (NXdeflector): (NXbeam): doc: | Individual characterization results for the position, shape, @@ -87,144 +88,6 @@ NXibeam_column(NXcomponent): :ref:`NXtransformations` should be used to specify the location or position at which details about the ion beam are probed. - (NXdeflector): - + (NXcomponent): # for further ideas and comments inspect version # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0a4f5073069eba5f9c0bafd732a6340cf9f4ba89e9be3d114c5dec61ef37b1aa -# -# -# -# -# -# -# Base class for a set of components equipping an instrument with FIB capabilities. -# -# Focused-ion-beam (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. The beam is intense enough and with sufficient ion momentum to -# remove material in a controlled 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 the definition of 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 flux -# -# -# -# -# Average/nominal brightness -# -# -# -# -# -# Charge current -# -# -# -# -# Ion acceleration voltage upon source exit and -# entering the vacuum flight path. -# -# -# -# -# To be defined more specifically. Community suggestions are welcome. -# -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the ion beam. -# -# :ref:`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.yaml b/contributed_definitions/nyaml/NXimage.yaml index 5edab3aed0..4cc394a540 100644 --- a/contributed_definitions/nyaml/NXimage.yaml +++ b/contributed_definitions/nyaml/NXimage.yaml @@ -1,6 +1,6 @@ category: base doc: | - Base class for reporting a set of images. + Base class for reporting a set of images representing specializations of NXdata. The most commonly used scanning methods are supported. That is one-, two-, three-dimensional ROIs discretized using regular Euclidean tilings. @@ -17,12 +17,10 @@ doc: | Point coordinates identify the location of the barycenter. For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode - images in reciprocal (frequency) space. FFT libraries are used for implementing the key functionalities of - these mathematical operations. - + Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal + (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations + Details can be found in the respective sections of the typical FFT libraries documentations: * `FFTW by M. Frigo and S. G. Johnson `_ * `Intel MKL by the Intel Co. `_ @@ -37,7 +35,7 @@ doc: | the number of images which are combined into collections is not necessarily the same for each collection. The NXimage base class addresses this logical distinction through the notation of indices_image and indices_group concepts. - That is indices_image are always counting from offset in increments of one. + That is indices_image are always counting from offset in increments of one as each image is its own entity. By contrast, a group may contain no, or several images. Consequently, indices_group are not required to be contiguous. diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml index 34327a051e..b2c1e835d9 100644 --- a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml @@ -1,6 +1,6 @@ category: base doc: | - Base class to group data and descriptions of the volume of interaction for particle-matter interaction. + Base class to describe the volume of interaction for particle-matter interaction. Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam interaction simulations can be used to qualify and (or) quantify the shape of diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index c8ce9a4f45..dbaa59122c 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -9,7 +9,7 @@ symbols: n_ranges: | Number of mass-to-charge-state-ratio range intervals for ion type. type: group -NXion(NXobject): +NXion(NXatom): id(NX_CHAR): doc: | A unique identifier whereby such an ion can be referred to @@ -56,48 +56,6 @@ NXion(NXobject): dimensions: rank: 2 dim: (n_ivecmax, 2) - - # color(NX_CHAR): - # doc: | - # Color code used for visualizing such ions. - volume(NX_NUMBER): - unit: NX_VOLUME - 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 alongside ranging - definitions. - charge(NX_NUMBER): - unit: NX_CHARGE - doc: | - Charge of the ion. - charge_state(NX_INT): - unit: NX_UNITLESS - doc: | - Signed charge state of the ion in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller `_ - name(NX_CHAR): - doc: | - Human-readable ion type name (e.g. Al +++) - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. mass_to_charge_range(NX_NUMBER): unit: NX_ANY doc: | From 67d3fd1463b527334c9482b44b259f6df28504f6 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 19:35:02 +0200 Subject: [PATCH 21/57] Fix issues with NXcs_computer --- .../NXcs_computer.nxdl.xml | 99 +------------------ contributed_definitions/NXcs_memory.nxdl.xml | 44 +++++++++ contributed_definitions/NXcs_process.nxdl.xml | 52 ++++++++++ .../nyaml/NXcs_computer.yaml | 65 +----------- .../nyaml/NXcs_memory.yaml | 16 +++ .../nyaml/NXcs_process.yaml | 24 +++++ .../nyaml/NXcs_storage.yml | 14 +++ 7 files changed, 156 insertions(+), 158 deletions(-) create mode 100644 contributed_definitions/NXcs_memory.nxdl.xml create mode 100644 contributed_definitions/NXcs_process.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_memory.yaml create mode 100644 contributed_definitions/nyaml/NXcs_process.yaml create mode 100644 contributed_definitions/nyaml/NXcs_storage.yml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 3910a494ea..873e856664 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -34,11 +34,6 @@ Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - - Version plus build number, commit hash, or description of an ever @@ -56,95 +51,7 @@ the Universally Unique Identifier (UUID) of the computing node. - - - - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. - - - - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU; describe using one instance of NXcircuit. - A dual-socket server; describe using two instances of NXcircuit. - A server with two dual-socket server nodes; describe with four - instances of NXcircuit surplus a field that defines their level - in the hierarchy. - - - - General type of the processing unit - - - - - - - - - - Given name - - - - - - - Details about the memory system. - - - - Granularizing the components of the memory system. - - - - Qualifier for the type of random access memory. - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - - - - Details about the I/O system. - - - - Granularizing the components of the I/O system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - + + + diff --git a/contributed_definitions/NXcs_memory.nxdl.xml b/contributed_definitions/NXcs_memory.nxdl.xml new file mode 100644 index 0000000000..8432a6b746 --- /dev/null +++ b/contributed_definitions/NXcs_memory.nxdl.xml @@ -0,0 +1,44 @@ + + + + + + Base class for reporting the description of the memory system of a computer. + + + + + Qualifier for the type of random access memory. + + + + + + + + + Total amount of data which the medium can hold. + + + + diff --git a/contributed_definitions/NXcs_process.nxdl.xml b/contributed_definitions/NXcs_process.nxdl.xml new file mode 100644 index 0000000000..859f90c57b --- /dev/null +++ b/contributed_definitions/NXcs_process.nxdl.xml @@ -0,0 +1,52 @@ + + + + + + Base class for reporting the description of processing units of a computer. + + Examples are e.g. (classical) processing units (CPUs), coprocessor, + graphic cards, accelerator processing units or a system of these. + + + + Typical examples for the granularization of processing units are: + + * A desktop computer with a single CPU; describe using one instance of NXcircuit. + * A dual-socket server; describe using two instances of NXcircuit. + * A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. + + + + General type of the processing unit + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 29a246a7c9..10fa91a008 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -9,9 +9,6 @@ NXcs_computer(NXobject): operating_system(NX_CHAR): doc: | Name of the operating system, e.g. Windows, Linux, Mac, Android. - enumeration: - open_enum: true - items: [windows, unix, macintosh] \@version(NX_CHAR): doc: | Version plus build number, commit hash, or description of an ever @@ -25,62 +22,6 @@ NXcs_computer(NXobject): doc: | 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 - processing(NXnote): - doc: | - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. - (NXcircuit): - doc: | - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU; describe using one instance of NXcircuit. - A dual-socket server; describe using two instances of NXcircuit. - A server with two dual-socket server nodes; describe with four - instances of NXcircuit surplus a field that defines their level - in the hierarchy. - type(NX_CHAR): - enumeration: - open_enum: true - items: [cpu, gpu, fpga] - doc: | - General type of the processing unit - name(NX_CHAR): - doc: | - Given name - memory(NXnote): - doc: | - Details about the memory system. - (NXcircuit): - doc: | - Granularizing the components of the memory system. - type(NX_CHAR): - doc: | - Qualifier for the type of random access memory. - enumeration: - open_enum: true - items: [ddr4, ddr5] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - name(NX_CHAR): - doc: | - Given name - storage(NXnote): - doc: | - Details about the I/O system. - (NXcircuit): - doc: | - Granularizing the components of the I/O system. - type(NX_CHAR): - doc: | - Qualifier for the type of storage medium used. - enumeration: [solid_state_disk, hard_disk, tape] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - name(NX_CHAR): - doc: | - Given name + (NXcs_process): + (NXcs_memory): + (NXcs_storage): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcs_memory.yaml b/contributed_definitions/nyaml/NXcs_memory.yaml new file mode 100644 index 0000000000..a166352198 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_memory.yaml @@ -0,0 +1,16 @@ +category: base +doc: | + Base class for reporting the description of the memory system of a computer. +type: group +NXcs_memory(NXcomponent): + (NXcircuit): + type(NX_CHAR): + doc: | + Qualifier for the type of random access memory. + enumeration: + open_enum: true + items: [ddr4, ddr5] + max_physical_capacity(NX_POSINT): + unit: NX_ANY + doc: | + Total amount of data which the medium can hold. diff --git a/contributed_definitions/nyaml/NXcs_process.yaml b/contributed_definitions/nyaml/NXcs_process.yaml new file mode 100644 index 0000000000..bc03154fce --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_process.yaml @@ -0,0 +1,24 @@ +category: base +doc: | + Base class for reporting the description of processing units of a computer. + + Examples are e.g. (classical) processing units (CPUs), coprocessor, + graphic cards, accelerator processing units or a system of these. +type: group +NXcs_processing(NXcomponent): + (NXcircuit): + doc: | + Typical examples for the granularization of processing units are: + + * A desktop computer with a single CPU; describe using one instance of NXcircuit. + * A dual-socket server; describe using two instances of NXcircuit. + * A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. + + type(NX_CHAR): + doc: | + General type of the processing unit + enumeration: + open_enum: true + items: [cpu, gpu, fpga] diff --git a/contributed_definitions/nyaml/NXcs_storage.yml b/contributed_definitions/nyaml/NXcs_storage.yml new file mode 100644 index 0000000000..b4ce472a8b --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_storage.yml @@ -0,0 +1,14 @@ +category: base +doc: | + Base class for reporting the description of the I/O of a computer. +type: group +NXcs_storage(NXcomponent): + (NXcircuit): + type(NX_CHAR): + doc: | + Qualifier for the type of storage medium used. + enumeration: [solid_state_disk, hard_disk, tape] + max_physical_capacity(NX_POSINT): + unit: NX_ANY + doc: | + Total amount of data which the medium can hold. From eaf5087af369c4230c5335bccb224084d6e0c45c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 20:04:49 +0200 Subject: [PATCH 22/57] Further work on EM base classes, added beam_blanker --- .../NXebeam_column.nxdl.xml | 7 + .../NXinstrument_em.nxdl.xml | 12 +- contributed_definitions/NXphase.nxdl.xml | 8 +- contributed_definitions/NXrotations.nxdl.xml | 177 +++++++++--------- contributed_definitions/NXscanbox_em.nxdl.xml | 14 +- contributed_definitions/NXunit_cell.nxdl.xml | 92 ++++++--- .../nyaml/NXebeam_column.yaml | 6 + .../nyaml/NXinstrument_em.yaml | 10 +- contributed_definitions/nyaml/NXphase.yaml | 6 +- .../nyaml/NXrotations.yaml | 3 + .../nyaml/NXscanbox_em.yaml | 14 +- .../nyaml/NXunit_cell.yaml | 27 ++- 12 files changed, 222 insertions(+), 154 deletions(-) diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 897d934f68..562a8b5d74 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -126,6 +126,13 @@ + + + A component for blanking the beam or generating pulsed electron beams. + See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ + or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. + + Device to improve energy resolution or chromatic aberration. diff --git a/contributed_definitions/NXinstrument_em.nxdl.xml b/contributed_definitions/NXinstrument_em.nxdl.xml index 7c93057fc0..5081843eb4 100644 --- a/contributed_definitions/NXinstrument_em.nxdl.xml +++ b/contributed_definitions/NXinstrument_em.nxdl.xml @@ -87,7 +87,7 @@ direct electron, CMOS, or image plate to name but a few. - + Stages in an electron microscope are multi-functional devices. @@ -134,7 +134,6 @@ - Principal design of the stage. @@ -215,14 +214,13 @@ in a particular narrow community which work with that particular microscope--> - In contrast to the stage, the nanoprobe is an additional manipulator that is specifically + In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and - relocated portions of the specimen that have been cut free to realize specialized - geometries locally and enable site-specific measurements. + relocated portions of the specimen that have been cut off during site-specific lift-outs + and specimen preparation. - - + diff --git a/contributed_definitions/NXphase.nxdl.xml b/contributed_definitions/NXphase.nxdl.xml index 8ac3855445..3448f7ec3c 100644 --- a/contributed_definitions/NXphase.nxdl.xml +++ b/contributed_definitions/NXphase.nxdl.xml @@ -63,14 +63,14 @@ Instance names should use ipf as a prefix. - + - Instance names should use pf as a prefix. + Instance names should use odf as a prefix. - + - Instance names should use odf as a prefix. + Instance names should use pf as a prefix. diff --git a/contributed_definitions/NXrotations.nxdl.xml b/contributed_definitions/NXrotations.nxdl.xml index 28b2d0847f..b23172a2a7 100644 --- a/contributed_definitions/NXrotations.nxdl.xml +++ b/contributed_definitions/NXrotations.nxdl.xml @@ -24,57 +24,60 @@ - 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. - The cardinality of the set, i.e. the number of value tuples. + The cardinality of the set, i.e. the number of value tuples. - How many phases with usually different crystal and symmetry are distinguished. + How many phases with usually different crystal and symmetry are distinguished. - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ - * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ - * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ - * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ + * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ + * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ + * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ + + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + + The concepts of mis- and disorientation are relevant when analyzing the + crystallography of interfaces. - Reference to an instance of :ref:`NXcoordinate_system` which contextualizes - how the here reported parameterized quantities can be interpreted. + Reference to an instance of :ref:`NXcoordinate_system` which contextualizes + how the here reported parameterized quantities can be interpreted. - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided, point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field needs to encode two strings: - The first string is for phase A. The second string is for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. + Point group which defines the symmetry of the crystal. + + This has to be at least a single string. If crystal_symmetry is not + provided, point group 1 is assumed. + + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field needs to encode two strings: + The first string is for phase A. The second string is for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. @@ -82,24 +85,24 @@ - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided, point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, have become obsolete thanks - to improvements in methods, software, and available computing power. + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided, point group 1 is assumed. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, have become obsolete thanks + to improvements in methods, software, and available computing power. + + Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). - Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed, and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description should be avoided. @@ -107,9 +110,9 @@ - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. @@ -118,11 +121,11 @@ - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many possible - Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many possible + Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. @@ -135,8 +138,8 @@ rotation_axis_angle(NX_NUMBER):--> - True for all those value tuples which have assumed antipodal symmetry. - False for all others. + True for all those value tuples which have assumed antipodal symmetry. + False for all others. @@ -144,10 +147,10 @@ rotation_axis_angle(NX_NUMBER):--> - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. + The set of orientations expressed in quaternion parameterization and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations with the antipodal property. @@ -156,11 +159,11 @@ rotation_axis_angle(NX_NUMBER):--> - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + The set of orientations expressed in Euler angle parameterization following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. @@ -172,13 +175,13 @@ orientation_homochoric(NX_NUMBER): orientation_axis_angle(NX_NUMBER):--> - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. + The set of misorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. - The misorientation should not be confused with the disorientation, - as for the latter the angular argument is expected to be the minimal - obeying symmetries. + The misorientation should not be confused with the disorientation, + as for the latter the angular argument is expected to be the minimal + obeying symmetries. @@ -187,8 +190,8 @@ orientation_axis_angle(NX_NUMBER):--> - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. @@ -196,8 +199,8 @@ orientation_axis_angle(NX_NUMBER):--> - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. @@ -208,9 +211,9 @@ orientation_axis_angle(NX_NUMBER):--> fundamental zone of SO3 for given crystal and sample symmetry--> - The set of disorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent disorientations - as defined by crystal_symmetry and sample_symmetry. + The set of disorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent disorientations + as defined by crystal_symmetry and sample_symmetry. @@ -219,10 +222,10 @@ fundamental zone of SO3 for given crystal and sample symmetry--> - Disorientations angular argument (should not be signed, see - `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. + Disorientations angular argument (should not be signed, see + `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. @@ -230,8 +233,8 @@ fundamental zone of SO3 for given crystal and sample symmetry--> - Disorientations axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. + Disorientations axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_angle. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 3b930d8a80..308b505b81 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -26,7 +26,7 @@ Scan box and coils which deflect a beam of charged particles in a controlled manner. The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, - which is not necessarily the same program as for all components of an instrument. + which is not necessarily the same program as the one controlling other parts of the instrument. The scanbox directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. @@ -35,13 +35,13 @@ Name of the typically tech-partner-specific term that specifies an - automated protocol which controls the details how the components - of the scan_box and instrument work together to achieve a controlled - scanning of the beam over the sample surface. + automated protocol which details how the components of the scan_box + and the instrument work together to achieve a controlled + scanning of the beam (over the sample surface). - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the instrument. - Instead, they often rely on the assumption that the microscope and control software + Oftentimes users do not need to or are not able to disentangle the intricate + details of the spatiotemporal dynamics of their instrument. Instead, often + they rely on the assumption that the instrument and its controlling programs work as expected. The field scan_schema can be used to add some constraints on how the beam was scanned over the surface. diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml index e4e53969e6..0c96674021 100644 --- a/contributed_definitions/NXunit_cell.nxdl.xml +++ b/contributed_definitions/NXunit_cell.nxdl.xml @@ -25,26 +25,26 @@ - Dimensionality of the lattice. + Dimensionality of the lattice. - Base class to describe structural aspects of an arrangement of - atoms or ions including a crystallographic unit cell. - - Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. + Base class to describe structural aspects of an arrangement of + atoms or ions including a crystallographic unit cell. + + Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. - Path to a reference frame in which the unit cell is defined - to resolve ambiguity in cases when e.g. a different reference frame - than the NeXus default reference frame (McStas) was chosen. + Path to a reference frame in which the unit cell is defined + to resolve ambiguity in cases when e.g. a different reference frame + than the NeXus default reference frame (McStas) was chosen. - Dimensionality of the structure. + Dimensionality of the structure. @@ -54,28 +54,57 @@ - Geometry of the unit cell quantified via parameters a, b, and c. + Geometry of the unit cell quantified via parameters a, b, and c. - + + + Geometry of the unit cell quantified individually via parameter a. + + + + + Geometry of the unit cell quantified individually via parameter b. + + + + + Geometry of the unit cell quantified individually via parameter c. + + - Geometry of the unit cell quantified via parameters alpha, beta, and gamma. + Geometry of the unit cell quantified via parameters alpha, beta, and gamma. + + + Geometry of the unit cell quantified individually via parameter alpha. + + + + + Geometry of the unit cell quantified individually via parameter beta. + + + + + Geometry of the unit cell quantified individually via parameter gamma. + + - Crystal system. - - For a crystal system in 2D space monoclinic is an exact synonym for oblique. - For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. - For a crystal system in 2D space tetragonal is an exact synonym for square. + Crystal system. + + For a crystal system in 2D space monoclinic is an exact synonym for oblique. + For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. + For a crystal system in 2D space tetragonal is an exact synonym for square. @@ -89,46 +118,47 @@ - Laue group using International Table of Crystallography notation. + Laue group using International Table of Crystallography notation. - Point group using International Table of Crystallography notation. + Point group using International Table of Crystallography notation. - Space group from the International Table of Crystallography notation. + Space group from the International Table of Crystallography notation. - 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 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. + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. - Area of the unit cell if dimensionality is 2. + Area of the unit cell if dimensionality is 2. - Volume of the unit cell if dimensionality is 3. + Volume of the unit cell if dimensionality is 3. + diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 8e412aef81..d9c8401afb 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -99,6 +99,12 @@ NXebeam_column(NXcomponent): (NXlens_em): (NXaperture): (NXdeflector): + blankerID(NXdeflector): + nameType: partial + doc: | + A component for blanking the beam or generating pulsed electron beams. + See e.g . `I. G. C. Weppelman et al. `_ + or `Y. Liao `_ for details. (NXmonochromator): doc: | Device to improve energy resolution or chromatic aberration. diff --git a/contributed_definitions/nyaml/NXinstrument_em.yaml b/contributed_definitions/nyaml/NXinstrument_em.yaml index bebf5d689e..e6eac002b2 100644 --- a/contributed_definitions/nyaml/NXinstrument_em.yaml +++ b/contributed_definitions/nyaml/NXinstrument_em.yaml @@ -55,7 +55,7 @@ NXinstrument_em(NXinstrument): 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. - (NXscanbox_em): + scan_controller(NXscanbox_em): stage(NXmanipulator): doc: | Stages in an electron microscope are multi-functional devices. @@ -102,7 +102,6 @@ NXinstrument_em(NXinstrument): # see for complicated positioning tools like an eucentric five-axis table stage in an SEM # https://www.nanotechnik.com/e5as.html - (NXfabrication): design(NX_CHAR): doc: | Principal design of the stage. @@ -169,13 +168,12 @@ NXinstrument_em(NXinstrument): dim: (3,) nanoprobe(NXmanipulator): doc: | - In contrast to the stage, the nanoprobe is an additional manipulator that is specifically + In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and - relocated portions of the specimen that have been cut free to realize specialized - geometries locally and enable site-specific measurements. + relocated portions of the specimen that have been cut off during site-specific lift-outs + and specimen preparation. # https://nano.oxinst.com/nanomanipulators. - (NXfabrication): (NXpump): (NXsensor): (NXactuator): diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml index 163f7d0a3e..53e829d225 100644 --- a/contributed_definitions/nyaml/NXphase.yaml +++ b/contributed_definitions/nyaml/NXphase.yaml @@ -35,9 +35,9 @@ NXphase(NXobject): (NXmicrostructure_ipf): doc: | Instance names should use ipf as a prefix. - (NXmicrostructure_pf): - doc: | - Instance names should use pf as a prefix. (NXmicrostructure_odf): doc: | Instance names should use odf as a prefix. + (NXmicrostructure_pf): + doc: | + Instance names should use pf as a prefix. diff --git a/contributed_definitions/nyaml/NXrotations.yaml b/contributed_definitions/nyaml/NXrotations.yaml index 5149ba6425..d4f3b8cf8d 100644 --- a/contributed_definitions/nyaml/NXrotations.yaml +++ b/contributed_definitions/nyaml/NXrotations.yaml @@ -18,6 +18,9 @@ doc: | (like crystal lattice) into a crystallographic equivalent orientation: * `R. Bonnet `_ + + The concepts of mis- and disorientation are relevant when analyzing the + crystallography of interfaces. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 350d84e3cc..e6aac9e0d8 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -3,7 +3,7 @@ doc: | Scan box and coils which deflect a beam of charged particles in a controlled manner. The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, - which is not necessarily the same program as for all components of an instrument. + which is not necessarily the same program as the one controlling other parts of the instrument. The scanbox directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. @@ -14,13 +14,13 @@ NXscanbox_em(NXcomponent): scan_schema(NX_CHAR): doc: | Name of the typically tech-partner-specific term that specifies an - automated protocol which controls the details how the components - of the scan_box and instrument work together to achieve a controlled - scanning of the beam over the sample surface. + automated protocol which details how the components of the scan_box + and the instrument work together to achieve a controlled + scanning of the beam (over the sample surface). - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the instrument. - Instead, they often rely on the assumption that the microscope and control software + Oftentimes users do not need to or are not able to disentangle the intricate + details of the spatiotemporal dynamics of their instrument. Instead, often + they rely on the assumption that the instrument and its controlling programs work as expected. The field scan_schema can be used to add some constraints on how the beam was scanned over the surface. diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index 463d81287c..7287886487 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -25,8 +25,18 @@ NXunit_cell(NXobject): dimensions: rank: 1 dim: (d,) - - # defined using which convention? + a(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter a. + b(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter b. + c(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter c. alpha_beta_gamma(NX_NUMBER): unit: NX_ANGLE doc: | @@ -34,6 +44,18 @@ NXunit_cell(NXobject): dimensions: rank: 1 dim: (d,) + alpha(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter alpha. + beta(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter beta. + gamma(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter gamma. crystal_system(NX_CHAR): doc: | Crystal system. @@ -75,6 +97,7 @@ NXunit_cell(NXobject): doc: | Volume of the unit cell if dimensionality is 3. (NXatom): + (NXion): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 4ba67e02f7c0510351f900e50337dc1662a9ceb9256ba3f0ea1d3c12c76e7e7d From 3a6add4806d79a7c7c0d870d8315e82b77dd0db8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 20:15:01 +0200 Subject: [PATCH 23/57] Edits em-domain-specific methods --- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- contributed_definitions/NXem_eds.nxdl.xml | 8 +------- contributed_definitions/nyaml/NXem_ebsd.yaml | 3 ++- contributed_definitions/nyaml/NXem_eds.yaml | 10 ++-------- 4 files changed, 6 insertions(+), 17 deletions(-) diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 64dd488738..96461f988a 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -453,7 +453,7 @@ Specific parameter relevant only for certain algorithms used. - + Details for each phase used as a model with which the patterns were indexed. Instances of :ref:`NXunit_cell` in this group must diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index a39e52e717..caa87c3243 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -22,9 +22,6 @@ # For further information, see http://www.nexusformat.org --> - @@ -108,9 +105,6 @@ energy typically the fastest direction--> However, a collection of instances of NXpeak with individual NXatom can be used to add isotopic information and other relevant context. - - - @@ -144,7 +138,7 @@ energy typically the fastest direction--> - + Individual element-specific EDS/EDX/EDXS/SXES mapping diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 99cca23f1e..0f371f5df4 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -314,7 +314,8 @@ NXem_ebsd(NXprocess): parameter(NXcollection): doc: | Specific parameter relevant only for certain algorithms used. - (NXphase): + phaseID(NXphase): + nameType: partial doc: | Details for each phase used as a model with which the patterns were indexed. Instances of :ref:`NXunit_cell` in this group must diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 4283acc634..0b69d411e3 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -10,10 +10,6 @@ doc: | In effect, the resulting three-dimensional elemental information mappings are truly the result of a correlation and post-processing of several measurements which is the field of correlative tomographic usage of electron microscopy. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction symbols: n_photon_energy: | Number of X-ray photon energy (bins) @@ -62,9 +58,6 @@ NXem_eds(NXprocess): This field can be used when creating instances of :ref:`NXpeak` is not desired. However, a collection of instances of NXpeak with individual NXatom can be used to add isotopic information and other relevant context. - dimensions: - rank: 1 - dim: (n_elements,) (NXpeak): doc: | Details about individual indexed peaks. @@ -90,7 +83,8 @@ NXem_eds(NXprocess): dimensions: rank: 1 dim: (n_iupac_line_names,) - (NXimage): + ELEMENT_SPECIFIC_MAP(NXimage): + nameType: any doc: | Individual element-specific EDS/EDX/EDXS/SXES mapping From 4c408b080c017e4594778088486727d720a71675 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 20:30:46 +0200 Subject: [PATCH 24/57] Fixing warning issues with the documentation building --- Makefile | 2 +- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 38 +- ...NXapm_paraprobe_distancer_results.nxdl.xml | 40 +- ...apm_paraprobe_intersector_results.nxdl.xml | 40 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 38 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 78 ++-- .../NXapm_paraprobe_selector_results.nxdl.xml | 58 ++- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 38 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 38 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 40 +- .../NXapm_paraprobe_tool_common.nxdl.xml | 127 +++--- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 124 +++--- contributed_definitions/NXcg_roi.nxdl.xml | 15 +- .../NXcoordinate_system.nxdl.xml | 11 +- contributed_definitions/NXcs_process.nxdl.xml | 2 +- .../NXapm_paraprobe_clusterer_results.yaml | 39 +- .../NXapm_paraprobe_distancer_results.yaml | 242 +---------- .../NXapm_paraprobe_intersector_results.yaml | 315 +-------------- .../NXapm_paraprobe_nanochem_results.yaml | 39 +- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 178 +-------- .../NXapm_paraprobe_selector_results.yaml | 152 +------ .../NXapm_paraprobe_spatstat_results.yaml | 38 +- .../NXapm_paraprobe_surfacer_results.yaml | 38 +- .../NXapm_paraprobe_tessellator_results.yaml | 378 +----------------- .../nyaml/NXapm_paraprobe_tool_common.yaml | 138 +------ .../NXapm_paraprobe_transcoder_results.yaml | 260 +----------- contributed_definitions/nyaml/NXcg_roi.yaml | 72 +--- .../nyaml/NXcoordinate_system.yaml | 169 -------- .../nyaml/NXcs_process.yaml | 2 +- 29 files changed, 510 insertions(+), 2239 deletions(-) diff --git a/Makefile b/Makefile index 2555d073aa..49f4013564 100644 --- a/Makefile +++ b/Makefile @@ -76,7 +76,7 @@ pdf :: cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.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/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index c1cf2bcd85..096092f767 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -263,26 +263,24 @@ - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index a1882331d7..3d22935c5b 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -3,7 +3,7 @@ - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index dd65baea33..ba99def335 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -3,7 +3,7 @@ - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 0ba13df6c8..10c9e889b0 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -3,7 +3,7 @@ - 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*. This iontype - is marked with a 0 in the iontypes array. + 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*. This iontype + is marked with a 0 in the iontypes array. @@ -70,12 +70,12 @@ - The iontype (identifier) 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 those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. + The iontype (identifier) 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 those elements are considered of which + a (molecular) ion is assumed composed according to the NXion instances. @@ -107,30 +107,28 @@ - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index bcbb21f6d1..671d1bda80 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -3,7 +3,7 @@ - Base class documenting the information common to tools of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data - management system. + Base class documenting the information common to tools of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The common section can be used as a place to store e.g. organizational + metadata and contextualization of that analysis in a research data + management system. - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - be that the tool has terminated prematurely or another error occurred. + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + be that the tool has terminated prematurely or another error occurred. @@ -62,67 +62,62 @@ - Internal identifier used by the tool to refer to an analysis (aka simulation - id). + Internal identifier used by the tool to refer to an analysis (aka simulation + id). - The configuration file that was used to parameterize - the algorithms that this tool has executed. + The configuration file that was used to parameterize + the algorithms that this tool has executed. +doc: | +Path where the tool stores tool-specific results. 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 the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. - Wall-clock time. + Wall-clock time. - + - 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: - - * paraprobe - * 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. + 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: + + * paraprobe + * 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. - - - - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 49631929b3..765be1c569 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -3,7 +3,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. - The total number of ions in the reconstruction. + 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. - Total number of integers in the supplementary XDMF topology array. + Total number of integers in the supplementary XDMF topology array. - Number of entries + Number of entries - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-transcoder tool is to create a standardized representation - of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. - This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - - So far the atom probe community has not yet agreed upon a comprehensive standardization on how to - exchange information especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, - APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document - their origin and thus the sequence in which the file was generated during an analysis. - - Paraprobe-transcoder solves this limitation by interpreting the information content in such files - and standardize the representation prior injection into the scientific data analysis tools of the toolbox. - Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point for the atom probe community to take advantage of standardized information - exchange and improve the here proposed classes and concepts to become more inclusive. - - Paraprobe-transcoder uses a Python library developed based on efforts by members of the - global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the - actual low-level I/O operations and respective information interpretation of above-mentioned file formats. + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-transcoder tool is to create a standardized representation + of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information + to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. + This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. + + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to + exchange information especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, + APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document + their origin and thus the sequence in which the file was generated during an analysis. + + Paraprobe-transcoder solves this limitation by interpreting the information content in such files + and standardize the representation prior injection into the scientific data analysis tools of the toolbox. + Therefore, the here proposed set of NeXus base classes and application definitions can be a useful + starting point for the atom probe community to take advantage of standardized information + exchange and improve the here proposed classes and concepts to become more inclusive. + + Paraprobe-transcoder uses a Python library developed based on efforts by members of the + global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the + actual low-level I/O operations and respective information interpretation of above-mentioned file formats. @@ -95,9 +95,9 @@ config--> - By default the entire reconstructed volume is processed. - In this case, using window is also equivalent to an - NXspatial_filter that specified a window *entire_dataset*. + By default the entire reconstructed volume is processed. + In this case, using window is also equivalent to an + NXspatial_filter that specified a window *entire_dataset*. @@ -107,7 +107,7 @@ config--> - Mass-to-charge-state-ratio values. + Mass-to-charge-state-ratio values. @@ -117,8 +117,8 @@ config--> - 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. @@ -126,17 +126,17 @@ config--> - Defines in which reference frame the positions are defined. + Defines in which reference frame the positions are defined. - 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. + 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. @@ -147,7 +147,7 @@ config--> - Details about how peaks are interpreted as ion types or not. + Details about how peaks are interpreted as ion types or not. @@ -189,30 +189,28 @@ config--> - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_roi.nxdl.xml b/contributed_definitions/NXcg_roi.nxdl.xml index e2d7a6cee5..404ab1bd16 100644 --- a/contributed_definitions/NXcg_roi.nxdl.xml +++ b/contributed_definitions/NXcg_roi.nxdl.xml @@ -3,7 +3,7 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - Use the depends_on fields of the respective specialized - :ref:`NXcg_primitive` base class surplus - :ref:`NXcoordinate_system_set` with at least one instance of - :ref:`NXcoordinate_system` to define explicitly the reference frame in - which the primitives are defined. Alternatively, although - discouraged, one may use one :ref:`NXcoordinate_system_set` with with - only one :ref:`NXcoordinate_system` in the application definition to - specify implicitly in which reference frame the primitives are - defined. If none of these two possibilities is used all primitives - are assumed defined in the McStas coordinate system. + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to + define explicitly the reference frame in which the primitives are + defined. diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index c6b1391a81..2fe95558f2 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ - + Base class for reporting the description of processing units of a computer. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 3d32112e7d..65f0962070 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -219,23 +219,22 @@ NXapm_paraprobe_clusterer_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 3d02a9dc7e..557e59b47b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -136,227 +136,21 @@ NXapm_paraprobe_distancer_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dd19c39460ee00e71df643b973731be56829f99741ceee5f79c9b03f2f147906 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of points, i.e. ions in the reconstruction. -# -# -# -# -# The total number of triangles in the set. -# -# -# -# -# Application definition for results files of the paraprobe-distancer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each -# member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the -# distance is computed as the projected distance, this tool evaluates robustly the exact distance between -# a point and a triangle. -# -# Triangles can represent for instance the facets of a triangulated surface mesh like those returned by -# paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. -# -# Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, -# what their topology is, or whether or not these triangles are consistently oriented. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The shortest analytical distance of each point to their -# respectively closest triangle from the joint triangle set. -# -# -# -# -# -# -# -# For each point the identifier of the triangle for which the -# shortest distance was found. -# -# -# -# -# -# -# -# A support field to enable the visualization of each point -# by an explicit identifier on the interval [0, n_ions - 1]. -# The field can be used to visualize the points as a function -# of their distance to the triangle set (e.g. via XDMF/Paraview). -# -# -# -# -# -# -# -# A bitmask that identifies which of the distance values is -# assumed to have a consistent sign because the closest -# triangle had a consistent outer unit normal defined. -# -# For points whose bit is set to 0 the distance is correct -# but the sign is not reliable. -# -# -# -# Number of triangles covered by the mask. -# -# -# -# -# Bitdepth of the elementary datatype that is used to store -# the information content of the mask (typically 8 bit, uint8). -# -# -# -# -# The content of the mask. Like for all masks used in the tools -# of the paraprobe-toolbox, padding is used when number_of_objects -# is not an integer multiple of bitdepth. If padding is used, -# padded bits are set to 0. -# -# -# -# -# -# -# -# -# A bitmask that identifies which of the triangles in the set were -# considered when certain triangles have been filtered out. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index aeb66b2f49..6c6adbeb17 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -188,300 +188,21 @@ NXapm_paraprobe_intersector_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 74f802b5eda5707493de0c5d4cf30d2e2e43a8cef7cfe50461d222e90cb414c4 -# -# -# -# -# -# -# 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 statistics. -# -# -# -# -# Application definition for results files of the paraprobe-intersector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# The results of an overlap/intersection analysis. -# -# -# -# -# A matrix of indices_feature that 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 volumetric overlap (0x00 == 0), proximity (0x01 == 1), -# or something else unknown (0xFF == 255). -# -# -# -# -# -# -# -# A matrix of indices_feature 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 are defined is symmetric it holds that next_to_current maps -# the links for current_to_next in just 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, pair relations -# are analyzed with respect to which objects with indices_feature -# cluster in identifier space. Thereby, a logical connection (link) is -# established between the features in the current_set and the next_set. -# Recall that these two sets 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 for precipitates B. -# -# Coprecipitation analysis now logically connects these independent -# characterization results to establish spatial correlations of e.g. -# the precipitates' spatial arrangement. -# -# -# -# Matrix of indices_feature and cluster_id pairs which -# encodes the cluster to which each indices_feature was assigned. -# Here for features of the current_set. -# -# -# -# -# -# -# -# -# Matrix of indices_feature and cluster_id pairs which -# encodes the cluster to which each indices_feature 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 third 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 981257efa4..71fdb5eabc 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -1051,23 +1051,22 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index cbc6e725c4..4f26cec5c3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -79,163 +79,21 @@ NXapm_paraprobe_ranger_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8ed505cdc4c9a5b12d46440106e56cb5bd341678e4723cb23b78618e0721905b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstructed volume. -# -# -# -# -# Application definition for results files of the paraprobe-ranger tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within -# a certain (possibly complicated) selection of ions (based on their properties or location in the -# reconstructed volume. -# -# -# -# -# -# -# -# -# -# -# -# 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*. This iontype -# is marked with a 0 in the iontypes array. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The iontype (identifier) 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 those elements are considered of which -# a (molecular) ion is assumed composed according to the NXion instances. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index e1bd260d89..078ed66bf3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -53,137 +53,21 @@ NXapm_paraprobe_selector_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 565310abf664825574450eaf8cdc518808782c8e129c4ca746eb8a4997476a9c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Application definition for results files of the paraprobe-selector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions -# are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). -# In addition, the tool allows to filter ions for properties. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index f285cd4790..fba1740640 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -129,23 +129,21 @@ NXapm_paraprobe_spatstat_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 3615f6ae12..a6ebdbd0c9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -196,23 +196,21 @@ NXapm_paraprobe_surfacer_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 7fcddcba3a..07669ebbd3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -248,363 +248,21 @@ NXapm_paraprobe_tessellator_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 23a20d6d97f05969af469661402f57d958807ac710ffb5e8d309792572a596b2 -# -# -# -# -# -# -# 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 values required to represent all faces of each cell. -# -# -# -# -# The total number of values required to represent all faces of each cell -# (polyhedron) using XDMF. -# -# -# -# -# Application definition for results files of the paraprobe-tessellator tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# The tool can be used to compute a Voronoi tessellation the entire -# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped -# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an -# axis-aligned bounding box (AABB) that is tight. This means points at -# the edge of the point cloud can lay on the surface of the bounding box. -# The tool detects if cells make contact with the walls of this bounding box. -# The tessellation is computed without periodic boundary conditions. -# -# -# -# -# -# -# -# -# -# -# The (tight) axis-aligned bounding box about the point cloud. -# -# -# -# Coordinate triplet of the corner that lays closest -# to the origin of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# Coordinate triplet of the corner that lays farthest away -# from the origin of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The number of points (and thus cells). -# -# -# -# -# Volume of each Voronoi cell. -# -# -# -# -# -# -# -# Which MPI process computed which Voronoi cell. -# -# -# -# -# -# -# -# Which OpenMP thread computed which Voronoi cell. -# -# -# -# -# -# -# -# The number of faces for each cell. Faces of adjoining polyhedra are counted -# for each polyhedron. This field can be used to interpret the concatenated vector -# with the individual values for the area of each face. -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of polyhedra when the main -# intention is to store the shape of the polyhedra for visualization purposes. -# -# -# -# -# -# -# -# -# -# Sequence of tuples, concatenated in the order of the Voronoi cells. -# Each tuple contains encodes information to visualize using XDMF: -# Firstly, an XDMF geometric primitive type key. -# Secondly, the number of vertices of the polygon. -# Third, the sequence of indices_vertex which define the facet. -# Tuples encode faces faster than cells. -# -# -# -# -# -# -# -# Sequence of cell identifier, concatenated such that each face is -# associated with its cell. Given that paraprobe-tessellator assigns -# each cell the evaporation_id of the ion that the cell wraps this -# information enables the segmentation of the tessellation and -# thus correlate per-ion properties with the volume that each cell -# represents. -# -# -# -# -# -# -# -# -# A bitmask that documents which of the cells are likely truncated because they -# share at least one face with the *aabb* of the point cloud. This field encodes the -# result of the boolean or operator applied to the value of all six wall_contact groups -# that document contact in specific outer unit normal directions of the *aabb*. -# -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the left face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# x-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the right face of *aabb*. -# Its outer unit normal points in the direction of the x-axis -# of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# y-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the rear face of *aabb*. -# Its outer unit normal points in the direction of the y-axis -# of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# z-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the direction of the z-axis of the -# *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 69f201eda4..30496c4beb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -62,7 +62,7 @@ NXapm_paraprobe_tool_common(NXobject): doc: | Wall-clock time. (NXuser): - (NXcoordinate_system_set): + (NXcoordinate_system): 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` @@ -82,139 +82,3 @@ NXapm_paraprobe_tool_common(NXobject): 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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3cb525c722bbd59598aaa02d81cb4bd739d771dd0448bf09808da5e7d8912e9f -# -# -# -# -# -# Base class documenting the information common to tools of the paraprobe-toolbox. -# -# The paraprobe-toolbox is a collection of open-source tools for performing -# efficient analyses of point cloud data where each point can represent atoms or -# (molecular) ions. A key application of the toolbox has been for research in the -# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): -# -# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ -# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ -# -# The toolbox does not replace but complements existent software tools in this -# research field. Given its capabilities of handling points as objects with -# properties and enabling analyses of the spatial arrangement of and inter- -# sections between geometric primitives, the software can equally be used -# for analyzing data in Materials Science and Materials Engineering. -# -# The common section can be used as a place to store e.g. organizational -# metadata and contextualization of that analysis in a research data -# management system. -# -# -# -# A statement whether the tool executable managed to process the analysis -# or whether this failed. Status is written to the results file after the -# end_time beyond which point in time the tool must no longer compute -# any further analysis results but exit. -# -# Only when this status message is present and its value is `success`, -# one should consider the results of the tool. In all other cases it might -# be that the tool has terminated prematurely or another error occurred. -# -# -# -# -# -# -# -# -# -# Internal identifier used by the tool to refer to an analysis (aka simulation -# id). -# -# -# -# -# The configuration file that was used to parameterize -# the algorithms that this tool has executed. -# -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis in this results file was started, -# i.e. when the respective executable/tool was started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis in this results file were -# completed and the respective process of the tool exited. -# -# -# -# -# Wall-clock time. -# -# -# -# -# -# -# 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: -# -# * paraprobe -# * 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. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 97aa785480..7ce5e945f4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -142,245 +142,21 @@ NXapm_paraprobe_transcoder_results(NXobject): doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: (3,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ef6b15a68ffaa7f8e9e7024bd00e81780b0bc81fb5fdd0a88ffc68fd74f54856 -# -# -# -# -# -# -# -# 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. -# -# -# -# -# Total number of integers in the supplementary XDMF topology array. -# -# -# -# -# Number of entries -# -# -# -# -# Application definition for results files of the paraprobe-transcoder tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-transcoder tool is to create a standardized representation -# of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information -# to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. -# This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. -# -# So far the atom probe community has not yet agreed upon a comprehensive standardization on how to -# exchange information especially when it comes to the communication of configurations and results -# from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, -# APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document -# their origin and thus the sequence in which the file was generated during an analysis. -# -# Paraprobe-transcoder solves this limitation by interpreting the information content in such files -# and standardize the representation prior injection into the scientific data analysis tools of the toolbox. -# Therefore, the here proposed set of NeXus base classes and application definitions can be a useful -# starting point for the atom probe community to take advantage of standardized information -# exchange and improve the here proposed classes and concepts to become more inclusive. -# -# Paraprobe-transcoder uses a Python library developed based on efforts by members of the -# global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the -# actual low-level I/O operations and respective information interpretation of above-mentioned file formats. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# By default the entire reconstructed volume is processed. -# In this case, using window is also equivalent to an -# NXspatial_filter that specified a window *entire_dataset*. -# -# -# -# -# -# -# -# -# -# Mass-to-charge-state-ratio values. -# -# -# -# -# -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# Interleaved array of x, y, z positions in the specimen space. -# -# -# -# -# -# -# -# Defines in which reference frame the positions are defined. -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# Details about how peaks are interpreted as ion types or not. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcg_roi.yaml b/contributed_definitions/nyaml/NXcg_roi.yaml index 9c9a75064a..0ae444def0 100644 --- a/contributed_definitions/nyaml/NXcg_roi.yaml +++ b/contributed_definitions/nyaml/NXcg_roi.yaml @@ -8,17 +8,8 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - Use the depends_on fields of the respective specialized - :ref:`NXcg_primitive` base class surplus - :ref:`NXcoordinate_system_set` with at least one instance of - :ref:`NXcoordinate_system` to define explicitly the reference frame in - which the primitives are defined. Alternatively, although - discouraged, one may use one :ref:`NXcoordinate_system_set` with with - only one :ref:`NXcoordinate_system` in the application definition to - specify implicitly in which reference frame the primitives are - defined. If none of these two possibilities is used all primitives - are assumed defined in the McStas coordinate system. - + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes + to define explicitly the reference frame in which the primitives are defined. # eventually redundant NXsolid_geometry? type: group NXcg_roi(NXobject): @@ -30,62 +21,3 @@ NXcg_roi(NXobject): # how to handle cases where multiple primitives should be included? # see comment to NXcg_triangle roi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d4de7955cd6f0f3cbe019c447bbddefa546b1dcc8f40357818e521232555edf -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# Use the depends_on fields of the respective specialized -# :ref:`NXcg_primitive` base class surplus -# :ref:`NXcoordinate_system_set` with at least one instance of -# :ref:`NXcoordinate_system` to define explicitly the reference frame in -# which the primitives are defined. Alternatively, although -# discouraged, one may use one :ref:`NXcoordinate_system_set` with with -# only one :ref:`NXcoordinate_system` in the application definition to -# specify implicitly in which reference frame the primitives are -# defined. If none of these two possibilities is used all primitives -# are assumed defined in the McStas coordinate system. -# -# -# -# Base class for a region-of-interest (ROI) bound by geometric primitives. -# -# So-called region-of-interest(s) (ROIs) are typically used to describe a -# region in space (and time) where an observation is made or for which -# a computer simulation is performed with given boundary conditions. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index ff22f17e78..ba80567602 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -1,15 +1,6 @@ category: base doc: | Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. type: group NXcoordinate_system(NXobject): origin(NX_CHAR): @@ -102,163 +93,3 @@ NXcoordinate_system(NXobject): doc: | Collection of axis-based translations and rotations to describe this coordinate system with respect to another coordinate system. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 28ae2682c92a10d15c61e03b8b733612e92c50c03daa8caea0396f153ba8ca59 -# -# -# -# -# -# Base class to detail a coordinate system (CS). -# -# Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as -# a member in an :ref:`NXcoordinate_system_set` and the name of the instance -# should be this alias. This may support a process whereby jargon when talking -# about coordinate systems and conventions may become cleaner for users -# because it is not evident for people outside a lab that terms like e.g. -# tip space or specimen space refer to the same coordinate system. -# This is an example of jargon used in e.g. the field of atom -# probe tomography. -# -# -# -# Human-readable field telling where the origin of this CS is. -# Exemplar values could be *left corner of the lab bench*, *door-handle* -# *pinhole through which the electron beam exists the pole piece*. -# *barycenter of the triangle*, *center of mass of the stone*. -# -# -# -# -# -# An alternative name given to that coordinate system. -# -# -# -# -# Coordinate system type. -# -# -# -# -# -# -# -# Handedness of the coordinate system if it is a Cartesian. -# -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the x-axis. -# -# -# -# -# Human-readable field telling in which direction the x-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent -# and as such is the world reference frame. -# -# Exemplar values could be direction of gravity. -# -# -# -# -# -# Base unit vector along the first axis which spans the coordinate system. -# This axis is frequently referred to as the x-axis in real space and -# the i-axis in reciprocal space. -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the y-axis. -# -# -# -# -# Human-readable field telling in which direction the y-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent -# and as such is the world reference frame. -# -# See docstring of x_alias for further details. -# -# -# -# -# Base unit vector along the second axis which spans the coordinate system. -# This axis is frequently referred to as the y-axis in real space and -# the j-axis in reciprocal space. -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the z-axis. -# -# -# -# -# Human-readable field telling in which direction the z-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent -# and as such is the world reference frame. -# -# See docstring of x_alias for further details. -# -# -# -# -# Base unit vector along the third axis which spans the coordinate system. -# This axis is frequently referred to as the z-axis in real space and -# the k-axis in reciprocal space. -# -# -# -# -# -# -# -# This specifies the relation to another coordinate system by pointing to the last -# transformation in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe this coordinate system -# with respect to another coordinate system. -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_process.yaml b/contributed_definitions/nyaml/NXcs_process.yaml index bc03154fce..87d14283d9 100644 --- a/contributed_definitions/nyaml/NXcs_process.yaml +++ b/contributed_definitions/nyaml/NXcs_process.yaml @@ -5,7 +5,7 @@ doc: | Examples are e.g. (classical) processing units (CPUs), coprocessor, graphic cards, accelerator processing units or a system of these. type: group -NXcs_processing(NXcomponent): +NXcs_process(NXcomponent): (NXcircuit): doc: | Typical examples for the granularization of processing units are: From 89a2fddbab64193f42071086b39444e35df5fd42 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 20:49:43 +0200 Subject: [PATCH 25/57] Few more fixes and make local running fine now --- contributed_definitions/NXcs_storage.nxdl.xml | 45 +++++++++++++++++++ .../NXinteraction_volume_em.nxdl.xml | 15 ++++--- .../{NXcs_storage.yml => NXcs_storage.yaml} | 0 .../nyaml/NXinteraction_volume_em.yaml | 15 ++++--- 4 files changed, 61 insertions(+), 14 deletions(-) create mode 100644 contributed_definitions/NXcs_storage.nxdl.xml rename contributed_definitions/nyaml/{NXcs_storage.yml => NXcs_storage.yaml} (100%) diff --git a/contributed_definitions/NXcs_storage.nxdl.xml b/contributed_definitions/NXcs_storage.nxdl.xml new file mode 100644 index 0000000000..0570ed4703 --- /dev/null +++ b/contributed_definitions/NXcs_storage.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + Base class for reporting the description of the I/O of a computer. + + + + + Qualifier for the type of storage medium used. + + + + + + + + + + Total amount of data which the medium can hold. + + + + diff --git a/contributed_definitions/NXinteraction_volume_em.nxdl.xml b/contributed_definitions/NXinteraction_volume_em.nxdl.xml index e7f1652e80..196b49640a 100644 --- a/contributed_definitions/NXinteraction_volume_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_volume_em.nxdl.xml @@ -41,14 +41,15 @@ Iso-contours could be computed from electron or particle flux through an imaginary control surface (the iso-surface) or energy-levels (e.g. the case of X-rays). Details depend on the model. - * Another explicit description is via theoretical models which may + * 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>`_ - * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ + + 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>`_ + * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ diff --git a/contributed_definitions/nyaml/NXcs_storage.yml b/contributed_definitions/nyaml/NXcs_storage.yaml similarity index 100% rename from contributed_definitions/nyaml/NXcs_storage.yml rename to contributed_definitions/nyaml/NXcs_storage.yaml diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml index b2c1e835d9..a116f7c682 100644 --- a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml @@ -18,14 +18,15 @@ doc: | Iso-contours could be computed from electron or particle flux through an imaginary control surface (the iso-surface) or energy-levels (e.g. the case of X-rays). Details depend on the model. - * Another explicit description is via theoretical models which may + * 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. `_ - * `J. F. Ziegler et al. `_ + + 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. `_ + * `J. F. Ziegler et al. `_ type: group NXinteraction_volume_em(NXobject): From b0fe310e65757b39baac4b1483eda8f9384dcab4 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 21:21:02 +0200 Subject: [PATCH 26/57] Fix copyrights --- contributed_definitions/NXapm.nxdl.xml | 2 +- contributed_definitions/NXapm_compositionspace_config.nxdl.xml | 2 +- contributed_definitions/NXapm_compositionspace_results.nxdl.xml | 2 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 2 +- .../NXapm_paraprobe_clusterer_results.nxdl.xml | 2 +- .../NXapm_paraprobe_distancer_config.nxdl.xml | 2 +- .../NXapm_paraprobe_distancer_results.nxdl.xml | 2 +- .../NXapm_paraprobe_intersector_config.nxdl.xml | 2 +- .../NXapm_paraprobe_intersector_results.nxdl.xml | 2 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 2 +- contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 2 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 2 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 2 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 2 +- .../NXapm_paraprobe_tessellator_results.nxdl.xml | 2 +- contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml | 2 +- .../NXapm_paraprobe_transcoder_results.nxdl.xml | 2 +- contributed_definitions/NXapm_reconstruction.nxdl.xml | 2 +- contributed_definitions/NXcg_hexahedron.nxdl.xml | 2 +- contributed_definitions/NXcg_parallelogram.nxdl.xml | 2 +- contributed_definitions/NXcg_polygon.nxdl.xml | 2 +- contributed_definitions/NXcg_polyhedron.nxdl.xml | 2 +- contributed_definitions/NXcg_roi.nxdl.xml | 2 +- contributed_definitions/NXcg_tetrahedron.nxdl.xml | 2 +- contributed_definitions/NXcg_triangle.nxdl.xml | 2 +- contributed_definitions/NXcoordinate_system.nxdl.xml | 2 +- contributed_definitions/NXcs_computer.nxdl.xml | 2 +- contributed_definitions/NXebeam_column.nxdl.xml | 2 +- contributed_definitions/NXem.nxdl.xml | 2 +- contributed_definitions/NXem_calorimetry.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- contributed_definitions/NXibeam_column.nxdl.xml | 2 +- contributed_definitions/NXinstrument_apm.nxdl.xml | 2 +- contributed_definitions/NXinstrument_em.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure.nxdl.xml | 2 +- .../NXmicrostructure_gragles_config.nxdl.xml | 2 +- .../NXmicrostructure_gragles_results.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_imm_config.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_imm_results.nxdl.xml | 2 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_odf.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_pf.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_score_config.nxdl.xml | 2 +- contributed_definitions/NXmicrostructure_score_results.nxdl.xml | 2 +- 45 files changed, 45 insertions(+), 45 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index a9991742a7..2cbc2e9233 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -3,7 +3,7 @@ # # -# Quantified aberration coefficient in an aberration_model. +# Quantified aberration coefficient in an aberration_model. +# +# For an introduction in the aberrations in electron microscopy +# see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and +# `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. +# Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. # # # -# Magnitude of the aberration +# Magnitude of the aberration # # # # -# Uncertainty of the magnitude of the aberration +# Uncertainty of the magnitude of the aberration # # # # -# Free-text description how magnitude_errors was quantified -# e.g. via the 95% confidence interval, variance, standard deviation, -# using which algorithm or statistical model. +# Free-text description how magnitude_errors was quantified +# e.g. via the 95% confidence interval, variance, standard deviation, +# using which algorithm or statistical model. # # # # -# Time elapsed since the last measurement. +# Time elapsed since the last measurement. # # # # -# 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. +# 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. # # # # -# Given name to this aberration. +# Given name to this aberration. # # # # -# Alias also used to name and refer to this specific type of aberration. +# Alias to name or refer to this specific type of aberration. # # # diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 6b9679506d..59c3dcffb1 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -63,6 +63,7 @@ NXapm(NXobject): run_number(NX_UINT): exists: recommended unit: NX_UNITLESS + # cannot be made required as for simulations you do not have a run number! doc: | The identifier whereby the experiment is referred to in the control software. @@ -446,7 +447,7 @@ NXapm(NXobject): x_direction(NX_CHAR): y_direction(NX_CHAR): z_direction(NX_CHAR): - measurement(NXapm_measurement): #### + measurement(NXapm_measurement): exists: optional doc: | Base class for collecting a session with a real atom probe or field-ion microscope. @@ -588,6 +589,7 @@ NXapm(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended + # wavelength and pulse_energy as dynamic/volatile quantities stored in event data part comment(NX_CHAR): doc: | @@ -595,12 +597,14 @@ NXapm(NXobject): eventID(NXevent_data_apm): nameType: partial exists: ['min', '0', 'max', 'unbounded'] + # all these cannot be made required because for LEAP only stored in RHIT/HITS # but for M-TAP and Oxcart these pieces of information are available. start_time(NX_DATE_TIME): exists: recommended end_time(NX_DATE_TIME): exists: recommended + # delta_time(NX_NUMBER): # pulse_id_offset(NX_INT): # pulse_id(NX_INT): @@ -609,10 +613,12 @@ NXapm(NXobject): reflectron(NXcomponent): exists: recommended voltage(NX_FLOAT): + # decelerate_electrode(NXlens_em): local_electrode(NXlens_em): exists: recommended voltage(NX_FLOAT): + # ion_detector(NXdetector): pulser(NXcomponent): exists: recommended @@ -645,9 +651,10 @@ NXapm(NXobject): dimensions: rank: 1 dim: (n,) - # laser geometry at the moment has neither a worked out example - # nor any feedback from the community despite the work from B. Gault - # on laser atom probe was granted a Leibnitz award + + # laser geometry at the moment has neither a worked out example + # nor any feedback from the community despite the work from B. Gault + # on laser atom probe was granted a Leibnitz award stage(NXmanipulator): temperature_sensor(NXsensor): measurement(NX_CHAR): @@ -664,6 +671,7 @@ NXapm(NXobject): exists: optional doc: | Simulation of ion extraction from matter via laser and/or voltage pulsing. + # future possibility to reuse concepts from NXinstrument_apm again without # the need for defining them again atom_probe(NXroi): @@ -1189,3 +1197,1315 @@ NXapm(NXobject): exists: recommended name(NX_CHAR): exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 50f616708b4d630624292cca62af60e5b55c1419688a32aff4c23873957cb138 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of hit qualities (hit types) distinguished. +# +# +# +# +# Number of delay-line wires of the detector. +# +# +# +# +# Number of bins used in the mass-to-charge-state-ratio spectrum. +# +# +# +# +# Number of pulses collected in between start_time and end_time resolved by an +# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of +# ions included in the reconstructed volume if the application definition is used +# to store results of an already reconstructed datasets. +# +# +# +# +# Number of pulses returned by the hit finding algorithm. +# Neither necessarily equal to p nor to n. +# +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# from which an instance of a reconstructed volume has been generated. +# These ions get new identifier assigned in the process (the so-called +# evaporation_id). This identifier must not be confused with +# the pulse_id. Typically smaller than both p_out and p_out. +# +# +# +# +# Application definition for atom probe and field ion microscopy experiments. +# +# +# +# +# +# +# +# +# +# +# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) +# which was used to generate this NeXus file instance. +# +# +# +# +# A collection of all programs and libraries which are considered relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# +# +# +# +# +# +# +# +# +# The identifier whereby the experiment is referred to in the control software. +# This is neither the specimen_name nor the experiment_identifier. For +# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the +# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. +# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, +# or the instruments at GPM in Rouen, use the identifier which matches +# best conceptually 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 (provided these +# RHIT or HITS files respectively are stored alongside a data artifact). +# With NXapm the RHIT or HITS can be stored via NXnote in the +# hit_finding algorithm section. +# +# 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. Such interrupted runs +# should be stored as individual :ref:`NXentry` instances in one NeXus file. +# +# +# +# +# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. +# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into this field. +# +# The reason is that such free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn in how far the +# current base classes need extension based on user feedback. +# +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the atom probe session started. If the exact duration of +# the measurement is not relevant start_time only should be used. +# +# Often though it is useful to specify both start_time and end_time to +# capture more detailed bookkeeping 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. For this +# purpose the :ref:`NXevent_data_apm` instance should be used. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the atom probe session ended. +# +# +# +# +# How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime +# +# +# +# +# +# +# +# +# +# +# +# +# +# What type of atom probe experiment is performed? This field is meant to +# inform research data management systems to allow filtering: +# +# * apt are experiments where the analysis_chamber has no imaging gas. +# experiment with LEAP instruments are typically performed such. +# * 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. +# few experiments of this type have been performed as this can be detrimental +# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). +# * other should be used in combination with the user specifying details +# in the experiment_documentation field. +# +# If NXapm is used for storing details about a simulation use other for now. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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 knowledge they have gained about the sample. +# There are cases where the specimen is machined further or exposed to +# external stimuli during the experiment. In this case, these details should +# not be stored under sample but suggestions should be made +# how this application definition can be improved. +# +# 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. For this specific application definitions/schemas can be +# used which are then arranged and documented with a description of the +# workflow so that actionable graphs become instantiatable. +# +# +# +# +# Qualifier whether the sample is a real (in which case is_simulation should be set to false) +# or a virtual one (in which case is_simulation should be set to true). +# +# +# +# +# Given name/alias for the sample. +# +# +# +# +# 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. +# +# In atom probe it is possible that the specimen may contain a few +# crystals only. In this case the grain_diameter is not a reliable +# descriptor. Reporting a grain size may be useful though as it allows +# judging if specific features are expected to be found in the +# detector hit map. +# +# +# +# +# Magnitude of the standard deviation of 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 a documentation of the annealing +# treatment as a function of time is available one should better +# rely on this information and have it stored alongside the NeXus file. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_temperature. +# +# +# +# +# Rate of the last quenching step. Knowledge about this value can give +# an idea how the sample was heat treated. However, there are many +# situations where one can imagine that the scalar value for just the +# quenching rate is insufficient. +# +# An example is when the sample was left in the furnace after the +# furnace was switched off. In this case the sample cools down with +# a specific rate of how this furnace cools down in the lab. +# Processes which in practice are often not documented. +# +# This can be problematic though because when the furnace door was left open +# or the ambient temperature in the lab changed, i.e. for a series of +# experiments where one is conducted on a hot summer day and the next +# during winter this can have an effect on the evolution of the microstructure. +# There are many cases where this has been reported to be an QA issue in industry, +# e.g. think about aging aluminum samples left on the factory +# parking lot on a hot summer day. +# +# +# +# +# Magnitude of the 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Qualifier whether the specimen is a real (in which case is_simulation should be set to false) +# or a virtual one (in which case is_simulation should be set to true). +# +# +# +# +# Given name an alias. Better use identifierNAME and identifier_parent instead. +# A single NXentry should be used only for the characterization of a single specimen. +# +# +# +# +# Identifier of the sample from which the specimen was cut or the string +# n/a. The purpose of this field is to support functionalities for +# tracking sample provenance via a research data management system. +# +# +# +# +# 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. Ideally, this +# matches the last timestamp that is mentioned in the digital resource +# pointed to by identifier_parent. +# +# 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. Additional time stamps prior to preparation_date +# should better be placed in resources which describe but which do not +# pollute the description here with prose. Resolving these connected +# pieces of information is considered within the responsibility of the +# research data management system. +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources pointed to by identifier_parent or walk through +# eventually deeply nested groups in data instances. +# +# +# +# +# Discouraged free-text field. +# +# +# +# +# Report if the specimen is polycrystalline, in which case it +# contains a grain or phase boundary, or if the specimen is a +# single crystal. +# +# +# +# +# Report if the specimen is amorphous. +# +# +# +# +# Ideally measured otherwise best elaborated guess of the initial radius of the +# specimen. +# +# +# +# +# Ideally measured otherwise best elaborated guess of the (initial) 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. +# +# +# +# +# +# The conventions used when reporting crystal orientations. +# We follow the best practices of the Material Science community +# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin. +# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) +# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge +# but other conventions are possible. Apart from undefined, proper Euler angles +# are distinguished from (improper) Tait-Bryan angles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parametrizations/representations according +# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# +# A collection of coordinate systems. Several Euclidean +# coordinate systems (CS) are used in the field of atom probe: +# +# * 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. +# +# 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 identifier interval. Typically, the set of +# ion evaporation sequence identifiers 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. +# +# To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. +# +# +# +# +# +# +# +# +# +# +# +# Base class for collecting a session with a real atom probe or field-ion microscope. +# +# Workflows used during experiments or simulations of atom probe and related field-evaporation +# research should be documented in more detail and be better contextualized not only because of +# ongoing developments and the tighter becoming connection between atom probe and other +# methods for material characterization foremost electron microscopy see e.g.: +# +# * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ +# * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ +# * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ +# * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ +# * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ +# +# to mention but a few. +# +# To arrive at a design of base classes and an application definition that can be used +# for both real and simulated atom probe experiments it is worthwhile to recall concepts that are +# related to events and (molecular) ions: +# +# * Pulsing events which are used to trigger ion extraction events. +# * Physical events and corresponding signal triggered by an ion hitting the detector. +# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. +# * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input +# and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are +# worthwhile to be considered further and eventually included in the reconstructed volume. +# * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually +# selected (molecular) ions based on which an instance of a reconstruction is created. +# * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values +# and charge states of the (molecular) ions to substantiate that some of these ions can be considered +# as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms +# and subsequent peak labeling. In the field of atom probe this these peak identification methods +# are known as ranging definitions. +# +# Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts +# are well distinguished. However, the algorithms used to transform correlations between pulses and physical events +# into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm. +# +# Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme +# where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier +# i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. +# That is evaporation_id values take the role of an implicit time and course of the experiment given that +# ion extraction physically is a sequential process. +# +# There is a number of research groups who build own instruments and share different aspects of their technical +# specifications and approaches how they apply data processing e.g.: +# +# * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ +# * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ +# * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ +# +# to name but a few. +# +# Despite some of these activities embrace practices of open-source development, they use essentially the same +# workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface +# software is used to explore and thus analyze reconstructed atom probe datasets. +# +# Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. +# Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which +# scientific conclusions about the characterized material volume are made. Also here a reconstruction is +# point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model. +# +# By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all +# the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. +# Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. +# We argue that this divide can be bridged with realizing the above-mentioned context and the realization that +# similar concepts are used in both research realms with many concepts not only being similar but being exactly the same. +# +# A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed +# datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment +# and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting +# a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as +# (spatial) filtering and reconstruction algorithms. +# +# Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation +# simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. +# Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. +# Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. +# Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require +# simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps +# in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. +# Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) +# than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path +# such as local electrodes or physical obstacles and electric fields (controlled or stray fields). +# +# +# +# A statement whether the measurement was successful or failed prematurely. +# +# +# +# +# +# +# +# +# CAnalysis.CResults.fQuality +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Free text field for additional comments. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Simulation of ion extraction from matter via laser and/or voltage pulsing. +# +# +# +# +# +# A region-of-interest analyzed either during or after the session for which +# specific processed data of the measured or simulated data are available. +# +# +# +# +# SEM or TEM image of the initial specimen (ideally taken prior data acquisition). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For almost atom probe instruments (meta)data about raw data follow proprietary semantics. +# Therefore, this group can currently be used only to point to these digital artifacts +# in an effort to document all step of an analysis workflow. +# +# The physical quantities measured in an atom probe experiment are time-of-flight and +# tuples of arrival_time_pairs as a function of the event chain on the pulser. +# From these tuples hits are computed in a process called hit_finding. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The number of wires in the detector. +# +# +# +# +# +# +# +# +# +# Alias tuple (begin, end) of each DLD wire of the detector. +# Order follows arrival_time_pairs. +# +# +# +# +# +# +# +# +# Raw readings from the analog-to-digital-converter +# timing circuits of the detector wires. +# +# +# +# +# +# +# +# +# +# +# Configuration of and results obtained from a hit finding algorithm. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Evaluated ion impact coordinates on the detector. +# Use the depends_on field to specify which reference +# frame the positions are defined. +# +# +# +# +# +# +# +# Defines in which reference frame the positions are defined. +# +# +# +# +# +# CRunHeader.fTotalEventGolden +# +# +# +# +# CRunHeader.fTotalEventIncomplete +# +# +# +# +# CRunHeader.fTotalEventMultiple +# +# +# +# +# CRunHeader.fTotalEventPartials +# +# +# +# +# CRunHeader.fTotalEventRecords +# +# +# +# +# Hit quality is an integer that specifies which category/type a hit was assigned to. +# This field lists the human-readable, possibly though proprietary types distinguished. +# The indices of this array are used in hit_quality to encode hit_quality for each +# pulse in a more efficient way than by repeating the string that is used for each +# type as it is provided in this field. +# +# As an example assume two types golden and partial are distinguished. +# If hit_quality_type stores the array "golden", "partial", the index 0 +# in hit_quality identifies all those pulses of category golden, +# while the index 1 in hit_quality identifies all of category partial. +# +# +# +# +# +# +# +# Hit quality identifier for each pulse. +# Identifier have to be within hit_quality. +# +# +# +# +# +# +# +# This processing yields for each ion with how many others it evaporated +# if these were collected on the same pulse. Extraction of multiple ions +# on one pulse on different or even the same pixel of the detector are possible. +# +# Multiplicity must not be confused with how many atoms of the same element +# a molecular ion contains. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Integer used to name the first pulse to know if there is an +# offset of the evaporation_id to zero. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# evaporation_id_offset and cardinality. For example if identifier run from +# -2 to 3 the value for evaporation_id_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where evaporation_id_offset is 1 and 0 respectively. +# +# +# +# +# (Molecular) ion identifier which resolves the sequence in which +# the ions were evaporated but taking into account that a hit_finding +# and spatial_filtering was applied. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. +# +# The voltage-and-bowl correction is a data post-processing step to correct ion impact +# positions for flight path differences, detector bias, and nonlinearities. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw time-of-flight data without corrections. +# +# +# +# +# +# +# +# +# The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate +# +# +# +# +# Calibrated time-of-flight. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For LEAP and IVAS/APSuite-based analyses root file which stores +# the settings whereby an RHIT/HITS file can be used to regenerate the +# reconstruction that is here referred to. +# +# The respective RHIT/HITS file should ideally be specified in the serialized +# group of the hit_finding section of this application definition. +# +# +# +# +# +# +# +# +# For LEAP and IVAS/APSuite-based analyses the resulting typically +# file with the reconstructed positions and (calibrated) mass-to-charge +# state ratio values. +# +# For other data collection/analysis software the data artifact which comes +# closest conceptually to AMETEK/Cameca's typical file formats. +# +# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, +# which should be stored alongside this record in the research data +# management system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The respective ranging definitions file RNG/RRNG/ENV/HDF5. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# (Out-of-sync) background levels in ppm/ns +# reported by e.g. IVAS/APSuite for LEAP systems. +# +# +# +# +# MRP, mass-resolving power, `D. Larson et al. +# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). +# +# +# +# +# MRP, at which mrp_value was specified. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Category for the peak offering a qualitative statement of the location of the peak +# in light of limited mass-resolving power that is relevant for +# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ +# for examples of each category: +# +# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` +# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` +# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states +# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` +# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` +# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index eff979cf0a..cdf4eeaf26 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -116,29 +116,235 @@ NXapm_compositionspace_config(NXobject): gaussian_mixture(NXprocess): exists: optional doc: | - Configuration for the Gaussian mixture model that is used in the segmentation step. + Configuration for the Gaussian mixture model that is used in the segmentation + step. clustering(NXprocess): doc: | - Step during which the chemically segmented voxel sets are analyzed for their spatial organization. + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. dbscan(NXparameters): doc: | Configuration for the DBScan algorithm that is used in the clustering step. eps(NX_FLOAT): unit: NX_LENGTH doc: | - The maximum distance between voxel pairs in a neighborhood to be considered connected. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. min_samples(NX_UINT): unit: NX_UNITLESS doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core point. - # meshing(NXprocess): - # doc: | - # TODO - # distance_cut(NX_NUMBER): - # doc: | - # TODO - # units: NX_ANY - # normal_end_length(NX_NUMBER): - # doc: | - # TODO - # units: NX_ANY + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + + # meshing(NXprocess): + # doc: | + # TODO + # distance_cut(NX_NUMBER): + # doc: | + # TODO + # units: NX_ANY + # normal_end_length(NX_NUMBER): + # doc: | + # TODO + # units: NX_ANY + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ca8663cc1ce83dc2b909222722579b297373777ad01ebda5c5fa954862339b06 +# +# +# +# +# +# Application definition for a configuration of the CompositionSpace tool used in atom probe. +# +# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ +# +# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure +# use case IUC09 that explores how to improve the organization and results storage of the +# CompositionSpace tool by using the NeXus data model and semantics. +# +# +# +# +# +# +# +# +# +# +# +# Specification of the tomographic reconstruction used for this analysis. +# Typically, reconstructions in the field of atom probe tomography are communicated via +# files which store at least reconstructed ion positions and mass-to-charge-state-ratio +# values. Container files like HDF5 though can store multiple reconstructions. +# Therefore, the position and mass_to_charge concepts point to specific instances +# to use for this analysis. +# +# +# +# +# +# +# +# Name of the node which resolves the reconstructed +# ion position values to use for this analysis. +# +# +# +# +# Name of the node which resolves the mass-to-charge-state ratio +# values for each reconstructed ion to use for this analysis. +# +# +# +# +# +# Specification of the ranging definitions used for this analysis. +# +# Indices start from 1. The value 0 is reserved for the null model of unranged positions whose +# iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. +# +# +# +# +# +# +# +# Name of the (parent) node directly below which the ranging definitions for +# (molecular) ions are stored. +# +# +# +# +# +# Step during which the point cloud is discretized to compute element-specific composition fields. +# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that +# was ranged for each ion. +# +# +# +# Edge length of cubic voxels building the 3D grid that is used for discretizing +# the point cloud. +# +# +# +# +# Optional step during which the subsequent segmentation step is prepared with the aim to eventually +# reduce the dimensionality of the chemical space in which the machine learning model works. +# +# In this step a supervised reduction of the dimensionality of the chemical space is quantified using +# the (Gini) feature importance of each element to suggest which columns of the composition matrix +# should be taken for the subsequent segmentation step. +# +# +# +# Was the automated phase assignment used? +# +# +# +# +# Estimated guess for which a Gaussian mixture model is evaluated to preprocess a result that +# is subsequently post-processed with a random_forest_classifier to lower the number of +# dimensions in the chemical space to the subset of trunc_species many elements with the +# highest feature importance. +# +# +# +# +# The number of elements to use for reducing the dimensionality. +# +# +# +# +# Configuration for the random forest classification model. +# +# +# +# +# +# +# Step during which the voxel set is segmented into voxel sets with different +# chemical composition. +# +# +# +# A principal component analysis of the chemical space to guide a decision into how many sets of voxels +# with different chemical composition the machine learning algorithm suggests to split the voxel set. +# +# +# +# +# The decision is guided through the evaluation of the information criterion +# minimization. +# +# +# +# The maximum number of chemical classes to probe with the Gaussian mixture model +# with which the voxel set is segmented into a mixture of voxels with that many different +# chemical compositions. +# +# +# +# +# Configuration for the Gaussian mixture model that is used in the segmentation +# step. +# +# +# +# +# +# +# Step during which the chemically segmented voxel sets are analyzed for their +# spatial organization. +# +# +# +# Configuration for the DBScan algorithm that is used in the clustering step. +# +# +# +# The maximum distance between voxel pairs in a neighborhood to be considered +# connected. +# +# +# +# +# The number of voxels in a neighborhood for a voxel to be considered as a core +# point. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 9ee048f9cf..b54423aa33 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -47,6 +47,7 @@ NXapm_compositionspace_results(NXobject): exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): + # config config(NXnote): doc: | @@ -306,3 +307,426 @@ NXapm_compositionspace_results(NXobject): specifies for which voxel in the grid clusters from this process were found. dimensions: dim: (n_voxels,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b58f5eaadbf095897f66b55f2637fa152aa25fa11bc1b71ae808b4065494548d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the grid. +# +# +# +# +# Total number of voxels. +# +# +# +# +# Total number of ions in the reconstructed dataset. +# +# +# +# +# Application definition for results of the CompositionSpace tool used in atom probe. +# +# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ +# +# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure +# use case IUC09 that explores how to improve the organization and results storage of the +# CompositionSpace software using NeXus. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# Configuration file that was used in this analysis. +# +# +# +# +# +# +# +# +# +# +# Contextualize back to the specimen from which the +# dataset was collected that was here analyzed with +# CompositionSpace tool. +# +# +# +# True, if the specimen that the reconstructed dataset +# describes is a simulated one. +# False, if the specimen that the reconstructed dataset +# describes is a real one. +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources pointed to by identifier_parent or walk through +# eventually deeply nested groups in data instances. +# +# +# +# +# +# Step during which the point cloud is discretized to compute element-specific composition fields. +# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that +# was ranged for each ion. +# +# Using a discretization grid that is larger than the average distance between reconstructed ion positions +# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods +# used in atom probe for characterizing microstructural features that use the ion position data directly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# Discrete coordinate of each voxel. +# +# +# +# +# +# +# +# +# +# For each ion, the identifier of the voxel into which the ion binned. +# +# +# +# +# +# +# +# +# Total number of weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms. +# +# +# +# +# +# +# +# +# Chemical symbol of the element from the periodic table. +# +# +# +# +# Element-specific weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms of this element. +# +# +# +# +# +# +# +# +# +# Optional step during which the subsequent segmentation step is prepared to +# improve the segmentation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Element identifier stored sorted in descending order of feature importance. +# +# +# +# +# +# +# Axis caption +# +# +# +# +# +# Element relative feature importance stored sorted in descending order of feature +# importance. +# +# +# +# +# +# +# Axis caption +# +# +# +# +# +# +# +# Step during which the voxel set is segmented into voxel sets with different +# chemical composition. +# +# +# +# PCA in the chemical space (essentially composition correlation analyses). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Explained variance values +# +# +# +# +# +# +# +# Elements identifier matching those from ENTRY/voxelization/ION +# as the principal component analysis. +# +# +# +# +# +# +# +# +# +# Information criterion minimization. +# +# +# +# +# +# +# +# +# +# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. +# +# +# +# n_components argument of the Gaussian mixture model. +# +# +# +# +# y_pred return values of the computation. +# +# +# +# +# +# +# +# +# Information criterion as a function of number of n_ic_cluster aka dimensions. +# +# +# +# +# +# +# +# Akaike information criterion values +# +# +# +# +# +# +# +# Bayes information criterion values +# +# +# +# +# +# +# +# Actual n_ic_cluster values used +# +# +# +# +# +# +# +# +# +# +# Step during which the chemically segmented voxel sets are analyzed for their spatial organization +# into different spatial clusters of voxels in the same chemical set but representing individual object +# not-necessarily watertight or topologically closed objects built from individual voxels. +# +# +# +# +# +# +# +# +# +# Respective DBScan clustering result for each segmentation/ic_opt case. +# +# +# +# +# +# The maximum distance between voxel pairs in a neighborhood +# to be considered connected. +# +# +# +# +# The number of voxels in a neighborhood for a voxel to be considered as a core +# point. +# +# +# +# +# Raw label return values +# +# +# +# +# +# +# +# Voxel identifier +# +# Using these identifiers correlated element-wise with the values in the label array +# specifies for which voxel in the grid clusters from this process were found. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_measurement.yaml b/contributed_definitions/nyaml/NXapm_measurement.yaml index 0f3bb2f99a..b756a12288 100644 --- a/contributed_definitions/nyaml/NXapm_measurement.yaml +++ b/contributed_definitions/nyaml/NXapm_measurement.yaml @@ -5,3 +5,36 @@ type: group NXapm_measurement(NXobject): (NXinstrument_apm): (NXevent_data_apm): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cfbcaef76d663e1534268b0962566339d141ee0823bb436380c4af94b71db259 +# +# +# +# +# +# Base class for documenting a measurement with an atom probe microscope. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 4aad1388a0..84ad1ff5c6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -309,3 +309,385 @@ NXapm_paraprobe_clusterer_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a2cf168bee2387ccb8f0c8cd2ba8610829d582cd9429a5ee6797c0e1eedb1022 +# +# +# +# +# +# +# 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. +# +# +# +# +# Application definition for a configuration file of the paraprobe-clusterer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many cluster_analysis tasks should the tool execute. +# +# +# +# +# This process maps results from a cluster analysis made with IVAS / AP Suite +# into an interoperable representation. IVAS / AP Suite usually exports such results +# as a list of reconstructed ion positions with one cluster label per position. +# These labels are reported via the mass-to-charge-state-ratio column of what is effectively +# a binary file that is formatted like a POS file but cluster labels written out using floating +# point numbers. +# +# +# +# +# +# +# +# +# +# +# +# File with the results of the cluster analyses that was computed with IVAS / AP suite +# (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). +# The information is stored in an improper (.indexed.) POS file as a matrix of floating +# point quadruplets, one quadruplet for each ion. The first three values of each +# quadruplet encode the position of the ion. The fourth value is the integer identifier +# of the cluster encoded as a floating point number. +# +# +# +# +# +# +# +# +# Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction +# for recovering for each position in the :ref:`NXnote` results the closest matching position +# (within floating point accuracy). This can be useful when users wish to recover the +# original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster +# results POS files that is referred to results. +# +# +# +# +# +# +# This process performs a cluster analysis on a +# reconstructed dataset or a ROI within it. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How should iontypes be considered during the cluster analysis. +# +# 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 nuclide structure. +# +# The value resolve_element will set an ion active and account as many times +# for it, as the (molecular) ion contains atoms of elements in the whitelist +# ion_query_nuclide_vector. +# +# The value resolve_isotope will set an ion active and account as many times +# for it, as the (molecular) ion contains nuclides in the whitelist +# ion_query_nuclide_vector. +# +# In effect, ion_query_nuclide_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 an ion of a molecular +# ion with more than one nuclide, say Ti O for example is counted potentially several +# times because at that position (reconstructed) position it has been assumed that +# there was a Ti and an O atom. This multiplicity affects the size of the feature and its +# chemical composition. +# +# +# +# +# +# +# +# +# Matrix of nuclide 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. +# +# +# +# +# +# +# +# +# +# Settings for DBScan clustering algorithm. For original details about the +# algorithm 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 a set of cluster analyses with different parameter is executed: +# +# * For tuple as many runs are performed as parameter values have been defined. +# * For combinatorics individual parameter arrays are looped over. +# +# As an example we may provide ten entries for eps and three entries for min_pts. +# If high_throughput_method is set to tuple, the analysis is invalid because we have +# an insufficient number of min_pts values to pair them with our ten eps values. +# By contrast, if high_throughput_method is set to combinatorics, the tool will run three +# individual min_pts runs for each eps value, resulting in a total of 30 analyses. +# +# A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ +# can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), +# one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. +# +# +# +# +# +# +# +# +# Array of epsilon (eps) parameter values. +# +# +# +# +# +# +# +# Array of minimum points (min_pts) 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 with different parameter values are composed, +# following the explanation for high_throughput_method of dbscan. +# +# +# +# +# +# +# +# +# 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_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 65f0962070..c3059fae0b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -238,3 +238,292 @@ NXapm_paraprobe_clusterer_results(NXobject): rank: 1 dim: (3,) +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b549210ac96c1a0b9159ec25b304a47b9e93907c4e4653712ce7d31e1df44001 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Number of clusters found. +# +# +# +# +# Application definition for results files of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Results of a DBScan clustering analysis. +# +# +# +# The epsilon (eps) parameter used. +# +# +# +# +# The minimum points (min_pts) parameter used. +# +# +# +# +# Number of members in the set which is partitioned into features. +# Specifically, this is the total number of targets filtered from the +# dataset, i.e. typically the number of clusters which is usually not and +# for sure not necessarily 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: +# * index_offset - 1 indicates an object belongs to no cluster. +# * index_offset - 2 indicates an object belongs to the noise category. +# +# Setting for instance index_offset to 1 recovers the commonly used +# case that objects of the noise category get the value of -1 and points of the +# unassigned category get the value 0. +# +# +# +# +# The evaporation (sequence) id (aka evaporation_id) to figure out +# which ions from the reconstruction were considered targets. The length +# of this array is not necessarily n_ions. +# Instead, it is the value of cardinality. +# +# +# +# +# +# +# +# +# The number of solutions found for each target. Typically, +# this value is 1 in which case the field can be omitted. +# Otherwise, this array is the concatenated set of values of solution +# tuples for each target that can be used to decode model_labels, +# core_sample_indices, and weight. +# +# +# +# +# +# +# +# The raw labels from the DBScan clustering backend process. +# The length of this array is not necessarily n_ions. +# Instead, it is typically the value of cardinality provided that each +# target has only one associated cluster. If targets are assigned to +# multiple cluster this array is as long as the total number of solutions +# found and +# +# +# +# +# +# +# +# The raw array of core sample indices which specify which of the +# targets are core points. +# +# +# +# +# +# +# +# Numerical label for each target (member in the set) aka cluster identifier. +# +# +# +# +# +# +# +# Categorical label(s) for each target (member in the set) aka cluster name(s). +# +# +# +# +# +# +# +# Weights for each target that specifies how probable the target is assigned to +# a specific cluster. +# +# For the DBScan algorithm and atom probe tomography this value is 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 nuclides of requested type. +# +# +# +# +# +# +# +# Are targets assigned to the noise category or not. +# +# +# +# +# +# +# +# Are targets assumed a core point. +# +# +# +# +# +# +# +# In addition to the detailed storage which members were grouped to which +# feature here summary statistics are stored that communicate e.g. how many +# cluster were found. +# +# +# +# +# Total number of targets in the set, i.e. ions that were filtered +# and considered in this cluster analysis. +# +# +# +# +# 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). +# +# +# +# +# +# Numerical identifier of each feature aka cluster_id. +# +# +# +# +# +# +# +# Number of members for each feature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 00db3c525a..6594b33517 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -66,8 +66,8 @@ NXapm_paraprobe_distancer_config(NXobject): number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - - # + + # evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -158,3 +158,205 @@ NXapm_paraprobe_distancer_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 75d8113fdf1f793aa6755135eb9817d5625b71bd094724914fdc685e36ec2d99 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Application definition for a configuration file of the paraprobe-distancer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specifies for which point the tool will compute distances. +# +# The value *default* configures that distances are computed for all points. +# The value *skin* configures that distances are computed only for those +# points which are not farther away located to a triangle than +# threshold_distance. +# +# +# +# +# +# +# +# +# Maximum distance for which distances are +# computed when *method* is *skin*. +# +# +# +# +# +# How many triangle sets to consider. +# Multiple triangle sets can be defined which are +# composed into one joint triangle set for the analysis. +# +# +# +# +# Each triangle_set that is referred to here should be a face_list_data_structure, +# i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) +# array of NX_UINT incident vertices of each facet. Vertex indices are assumed to +# start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. +# Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex positions for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex indices for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex normal vectors for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of facet normal vectors for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of identifier for the triangles in that triangle_set. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 557e59b47b..dbb0272655 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -154,3 +154,205 @@ NXapm_paraprobe_distancer_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 951432cc2ac4d93cafff1dde53c40f83d0f5b24cb915eca1fdf65fc2fe9fc79c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of points, i.e. ions in the reconstruction. +# +# +# +# +# The total number of triangles in the set. +# +# +# +# +# Application definition for results files of the paraprobe-distancer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each +# member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the +# distance is computed as the projected distance, this tool evaluates robustly the exact distance between +# a point and a triangle. +# +# Triangles can represent for instance the facets of a triangulated surface mesh like those returned by +# paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. +# +# Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, +# what their topology is, or whether or not these triangles are consistently oriented. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The shortest analytical distance of each point to their +# respectively closest triangle from the joint triangle set. +# +# +# +# +# +# +# +# For each point the identifier of the triangle for which the +# shortest distance was found. +# +# +# +# +# +# +# +# A support field to enable the visualization of each point +# by an explicit identifier on the interval [0, n_ions - 1]. +# The field can be used to visualize the points as a function +# of their distance to the triangle set (e.g. via XDMF/Paraview). +# +# +# +# +# +# +# +# A bitmask that identifies which of the distance values is +# assumed to have a consistent sign because the closest +# triangle had a consistent outer unit normal defined. +# +# For points whose bit is set to 0 the distance is correct +# but the sign is not reliable. +# +# +# +# Number of triangles covered by the mask. +# +# +# +# +# Bitdepth of the elementary datatype that is used to store +# the information content of the mask (typically 8 bit, uint8). +# +# +# +# +# The content of the mask. Like for all masks used in the tools +# of the paraprobe-toolbox, padding is used when number_of_objects +# is not an integer multiple of bitdepth. If padding is used, +# padded bits are set to 0. +# +# +# +# +# +# +# +# +# A bitmask that identifies which of the triangles in the set were +# considered when certain triangles have been filtered out. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 2ca1a0c532..b2fae546fb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -32,6 +32,7 @@ NXapm_paraprobe_intersector_config(NXobject): step :math:`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. + # config intersection_detection_method(NX_CHAR): doc: | @@ -204,3 +205,283 @@ NXapm_paraprobe_intersector_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b01cf7e09c4868ebdcc29e501462fedcba3edc0d510308ebc1be419060503670 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of entries +# +# +# +# +# Application definition for a configuration file of the paraprobe-intersector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many v_v_spatial_correlation tasks should the tool execute. +# +# +# +# +# Tracking volume_volume_spatial_correlations (v_v) is the process of building logical +# relations between objects, their proximity and eventual volumetric intersections. +# Here, objects are assumed to be represented as a set of triangulated surface meshes. +# +# 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 :math:`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. +# +# +# +# +# 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>`_, +# it is assumed by default 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 tetrahedralization library used in the tests (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. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron +# intersections in paraprobe-intersector. +# +# +# +# +# +# +# +# Specifies if the tool evaluates if objects intersect volumetrically. +# +# +# +# +# Specifies if the tool evaluates if objects lay closer to one another than +# threshold_proximity. +# +# +# +# +# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting +# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ +# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, +# duplet, triplet, or high-order local groups. +# +# +# +# +# +# The maximum Euclidean distance between two objects below which they are +# 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 can be interpreted as the time/iteration (i.e. :math:`k`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# +# +# +# +# +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID 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. +# +# +# +# +# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the +# members of the set as instances of NXcg_polyhedron. +# +# +# +# Descriptive category explaining what these features are. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. +# +# +# +# +# +# Array of identifier whereby the path to the geometry data can be inferred +# 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 current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# +# +# +# +# +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. +# +# +# +# +# +# Array of identifier whereby the path to the geometry data can be inferred +# automatically. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 6c6adbeb17..09c8c85d79 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -206,3 +206,278 @@ NXapm_paraprobe_intersector_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fc5d07680b423f6c20340b57ce4a43d41ff2530f0859529046003134ccc85e49 +# +# +# +# +# +# +# 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 statistics. +# +# +# +# +# Application definition for results files of the paraprobe-intersector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# The results of an overlap/intersection analysis. +# +# +# +# +# A matrix of indices_feature that 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 volumetric overlap (0x00 == 0), proximity (0x01 == 1), +# or something else unknown (0xFF == 255). +# +# +# +# +# +# +# +# A matrix of indices_feature 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 are defined is symmetric it holds that next_to_current maps +# the links for current_to_next in just 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, pair relations +# are analyzed with respect to which objects with indices_feature +# cluster in identifier space. Thereby, a logical connection (link) is +# established between the features in the current_set and the next_set. +# Recall that these two sets 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 for precipitates B. +# +# Coprecipitation analysis now logically connects these independent +# characterization results to establish spatial correlations of e.g. +# the precipitates' spatial arrangement. +# +# +# +# Matrix of indices_feature and cluster_id pairs which +# encodes the cluster to which each indices_feature was assigned. +# Here for features of the current_set. +# +# +# +# +# +# +# +# +# Matrix of indices_feature and cluster_id pairs which +# encodes the cluster to which each indices_feature 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 third 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 71fdb5eabc..25fc960eb7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -1070,3 +1070,1259 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (3,) +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d9263811b4a8965809843c181f09eab3174c6e343607104b5781a2bc4358b476 +# +# +# +# +# +# +# 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 faces of triangles. +# +# +# +# +# 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 volumetric features. +# +# +# +# +# The total number of member distinguished when reporting composition. +# +# +# +# +# The total number of ROIs placed in an oned_profile task. +# +# +# +# +# Application definition for results files of the paraprobe-nanochem tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How were results of the kernel-density estimation normalized: +# * total, the total number (intensity) of ions or elements. +# * candidates, the total number (intensity) of ions matching weighting_model +# * composition, the value for candidates divided by the value for total, +# * concentration, the value for candidates divided by the volume of the cell. +# +# +# +# +# +# +# +# +# +# +# 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-dimensional base 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. +# +# +# +# +# +# +# +# +# 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 :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Functional form of the kernel (Ansatz function). +# +# +# +# +# +# +# +# Standard deviation :math:`\sigma_i` 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 :math:`\mu_i` of the kernel in each dimension +# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# +# +# +# +# +# +# +# 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 +# :math:`[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 +# :math:`[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 +# :math:`[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: :math:`[\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 :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces +# will be computed. In commercial software so far there is no possibility to export this information. +# +# If the intensity for all matches of the weighting_model are summarized name this NXdata instance +# scalar_field_magn_total. +# +# If the intensity is reported for each iontype one can avoid many subsequent +# computations as individual intensities can be reinterpreted using a different weighting_model in +# down-stream usage of the here reported values (e.g. with Python scripting). +# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as +# per the configuration of the ranging definitions used. +# +# +# +# +# +# +# +# +# +# The actual delocalized intensity values. +# +# +# +# +# +# +# +# +# +# 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 XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# The three-dimensional gradient :math:`\nabla \Phi`. +# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. +# +# +# +# +# +# +# +# +# +# The actual point-wise component values. +# +# +# +# +# +# +# +# +# +# +# Cell center of mass positions along x. +# +# +# +# +# +# +# +# Cell center of mass positions along y. +# +# +# +# +# +# +# +# Cell center of mass positions along z. +# +# +# +# +# +# +# +# The gradient vector formatted for direct visualization via XDMF in e.g. +# Paraview. +# +# +# +# +# +# +# +# +# Center of mass positions of each voxel for rendering the scalar field gradient +# via XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# XDMF topology for rendering in combination with xdmf_xyz the scalar field +# via XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# +# An iso-surface is the boundary between two regions across which the magnitude of a +# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. +# +# For applications in atom probe microscopy, the location and shape of such a boundary (set) +# is typically approximated by discretization - triangulation to be specific. +# +# 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 :math:`\varphi`. +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to a unique set as this may +# result in 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 each +# vertex is stored even though many share the same positions. +# +# +# +# +# +# +# +# +# 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: :math:`[\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. +# :math:`\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 the 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 representation of such iso-surface. +# This may yield a set of connected features whose individual surfaces are discretized +# by a triangulated mesh each. Such volumetric features can be processed further using +# paraprobe-nanochem using a workflow with at most two steps. +# +# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: +# +# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. +# These objects were already watertight within the triangulated iso-surface. +# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated +# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh +# processing operations (hole filling, refinement, fairing operations). +# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality +# that are not transformable into proxies or for which no transformation into proxies was +# instructed. +# +# 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. +# +# In the second step, the tool can be used to analyze the proximity of these objects to a +# model of the surface (edge) of the dataset. +# +# +# +# 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. +# +# +# +# +# +# +# +# In all situations instances of the parent NXprocess group are returned with a very similar +# information structuring and thus we here replace the template name FEATURE +# with one of the following types feature-specific group names: +# +# * objects, objects, irrespective their distance to the surface +# * objects_close_to_edge, sub-set of v_feature_object close surface +# * objects_far_from_edge, sub-set of v_feature_object not close to the surface +# * proxies, proxies, irrespective their distance to the surface +# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface +# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface +# +# +# +# Explicit identifier of the feature a sub-set of the indices_feature in the +# parent group. +# +# +# +# +# +# +# +# Volume of the feature. NaN for non-watertight objects. +# +# +# +# +# +# +# +# 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 or second-largest over largest and smallest over second largest. +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_id / identifier_ion which details which ions +# lie inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# Total (count) of ions inside or on the surface of the feature relevant for normalization. +# NaN for non watertight objects. +# +# +# +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total, yields the composition of this element, +# nuclide, or (molecular) ion within the volume of the feature/object. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# 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 fitted initially. +# +# +# +# The four parameter :math:`ax + by + cz + d = 0` which define the plane. +# +# +# +# +# +# +# +# +# The triangle surface mesh representing the interface model. +# Exported at state before or after the next DCOM step. +# +# +# +# Was this state exported before or after the next DCOM step. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each vertex normal. +# +# +# +# +# +# +# +# +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each face normal. +# +# +# +# +# +# +# +# +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 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 we discretize +# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, +# resolves the lateral surface of each cylinder such that their renditions are smooth in +# visualization software like Paraview. +# +# +# +# +# +# Position of the geometric center, which often is but not +# necessarily has to be the center_of_mass of the polyhedra. +# +# +# +# +# +# +# +# +# The orientation of the ROI defined via a vector which points along +# the cylinder axis and whose length is the height of the cylinder. +# +# +# +# +# +# +# +# +# +# XDMF support to enable coloring each ROI by its identifier. +# +# +# +# +# +# +# +# XDMF support to enable coloring each ROI whether it has edge contact or not. +# +# +# +# +# +# +# +# XDMF support to enable coloring each ROI by its number of atoms. +# +# +# +# +# +# +# +# XDMF support to enable coloring each ROI by its number of ions. +# +# +# +# +# +# +# +# Distance and iontype-specific processed data for each ROI. +# Arrays signed_distance and nuclide_hash are sorted by increasing +# distance. +# Array nuclide_hash reports one hash for each atom of each isotope. +# Effectively, this can yield to groups of values on signed_distance +# with the same distance value as molecular ions are reported decomposed +# into their atoms. +# Therefore, the XDMF support fields number_of_atoms and number_of_ions +# are only expected to display pairwise the same values respectively, +# if all ions are built from a single atom only. +# +# +# +# +# Sorted in increasing order projected along the positive direction +# of the ROI as defined by orientation in the parent group. +# +# +# +# +# +# +# +# Hashvalue as defined in :ref:`NXion`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 4f26cec5c3..cfbfe70f27 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -97,3 +97,141 @@ NXapm_paraprobe_ranger_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9ebf077a701c882987717f3ef00b14b8ce16aba802a82a88d84b3ae99060f6d7 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstructed volume. +# +# +# +# +# Application definition for results files of the paraprobe-ranger tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within +# a certain (possibly complicated) selection of ions (based on their properties or location in the +# reconstructed volume. +# +# +# +# +# +# +# +# +# +# +# +# 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*. This iontype +# is marked with a 0 in the iontypes array. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The iontype (identifier) 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 those elements are considered of which +# a (molecular) ion is assumed composed according to the NXion instances. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 078ed66bf3..85f15978fa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -71,3 +71,115 @@ NXapm_paraprobe_selector_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 22b11a8cbd32c1807ce143652a2864ed45bbfd5e04cea4808e53cf674cc8555d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Application definition for results files of the paraprobe-selector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions +# are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). +# In addition, the tool allows to filter ions for properties. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 2088a4803b..cdf58f3d22 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -264,3 +264,343 @@ NXapm_paraprobe_spatstat_config(NXobject): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# aa4765ea16ade592579becaa65d9e6ab9182a9e0cf5b0605a2afb02df069fc82 +# +# +# +# +# +# +# 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 source iontypes to distinguish. +# +# +# +# +# Number of different target iontypes to distinguish. +# +# +# +# +# Application definition for a configuration file of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many spatial_statistics tasks should the tool execute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# +# Threshold to define how far an ion has to lay at least from the edge +# of the dataset so that the ion can act as a source. This means that +# an ROI is placed at the location of the ion and its neighbors are +# analyzed how they contribute to the computed statistics. +# +# The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a +# microstructural feature an ROI is placed. +# +# The threshold is useful to process the dataset such that ROIs do +# not protrude out of the dataset as this would add bias. +# +# +# +# +# +# Distance between each ion and triangulated mesh of microstructural features. +# 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 the feature_distance +# threshold value. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file which points to the distance of each +# ion to the closest feature. +# +# +# +# +# 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 this feature_distance threshold is used in combination +# with the edge_distance threshold when placing ROI about source ions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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 +# iontypes randomly across the entire set of ions. That is the total +# number of ions of either type remain the same but the information about +# their location is randomized. +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# 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_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index fba1740640..9194f8ed7d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -147,3 +147,204 @@ NXapm_paraprobe_spatstat_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 84ba34d321c7c536c637ca707cafed4620b0a7193936da5758a41fe34d1844ae +# +# +# +# +# +# +# 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 bins in the histogram for the k-th nearest neighbor. +# +# +# +# +# The total number of bins in the histogram for the radial distribution function. +# +# +# +# +# Application definition for results files of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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 remain the same. +# +# The order matches the iontypes array from a given ranging results +# as it is specified in the configuration settings inside the specific +# config_filename that was used for this paraprobe-spatstat analysis. +# +# +# +# +# +# +# +# K-nearest neighbor statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated not normalized by total counts. +# +# +# +# +# +# +# +# Cumulated and normalized by total counts. +# +# +# +# +# +# +# +# +# Radial distribution statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated not normalized by total counts. +# +# +# +# +# +# +# +# Cumulated and normalized by total counts. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index a6ebdbd0c9..6cf8ef9197 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -214,3 +214,293 @@ NXapm_paraprobe_surfacer_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4de91ac370b6986c72fe2e7aa69bfdcb3854e2604b9d46693049d322da8f92e4 +# +# +# +# +# +# +# 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. +# +# +# +# +# Application definition for results files of the paraprobe-surfacer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-surfacer tool is the generation of meshed +# representation of the surface of the the reconstructed volume (or a portion) of it +# using different algorithms from the computational geometry community. +# +# +# +# +# +# +# +# +# +# +# +# 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 +# that alpha_complex instance was computed. +# +# This window can be different to the window of the *point_set_wrapping* +# parent group because irrelevant ions might have been filtered out in addition +# to the window defined in *point_set_wrapping* to reduce e.g. computational +# costs of the alpha complex computation. +# +# +# +# +# Number of ions covered by the mask. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# +# +# +# +# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for +# how this bitfield is to be interpreted. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The set of triangles in the coordinate system paraprobe +# which discretizes the exterior surface of the alpha complex. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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 that is watertight? +# +# +# +# +# The volume which the triangulated surface mesh +# encloses if that mesh is watertight. +# +# +# +# +# +# +# The set of tetrahedra which represent the interior volume +# of the complex if that is a closed two-manifold. +# +# +# +# +# The accumulated volume of all interior tetrahedra. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 07669ebbd3..19dddf4773 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -266,3 +266,341 @@ NXapm_paraprobe_tessellator_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 732dead16e97108fe50a00efedc173cf97f0857edd32c358566ad40da9914463 +# +# +# +# +# +# +# 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 values required to represent all faces of each cell. +# +# +# +# +# The total number of values required to represent all faces of each cell +# (polyhedron) using XDMF. +# +# +# +# +# Application definition for results files of the paraprobe-tessellator tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# The tool can be used to compute a Voronoi tessellation the entire +# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped +# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an +# axis-aligned bounding box (AABB) that is tight. This means points at +# the edge of the point cloud can lay on the surface of the bounding box. +# The tool detects if cells make contact with the walls of this bounding box. +# The tessellation is computed without periodic boundary conditions. +# +# +# +# +# +# +# +# +# +# +# The (tight) axis-aligned bounding box about the point cloud. +# +# +# +# Coordinate triplet of the corner that lays closest +# to the origin of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# Coordinate triplet of the corner that lays farthest away +# from the origin of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The number of points (and thus cells). +# +# +# +# +# Volume of each Voronoi cell. +# +# +# +# +# +# +# +# Which MPI process computed which Voronoi cell. +# +# +# +# +# +# +# +# Which OpenMP thread computed which Voronoi cell. +# +# +# +# +# +# +# +# The number of faces for each cell. Faces of adjoining polyhedra are counted +# for each polyhedron. This field can be used to interpret the concatenated vector +# with the individual values for the area of each face. +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of polyhedra when the main +# intention is to store the shape of the polyhedra for visualization purposes. +# +# +# +# +# +# +# +# +# +# Sequence of tuples, concatenated in the order of the Voronoi cells. +# Each tuple contains encodes information to visualize using XDMF: +# Firstly, an XDMF geometric primitive type key. +# Secondly, the number of vertices of the polygon. +# Third, the sequence of indices_vertex which define the facet. +# Tuples encode faces faster than cells. +# +# +# +# +# +# +# +# Sequence of cell identifier, concatenated such that each face is +# associated with its cell. Given that paraprobe-tessellator assigns +# each cell the evaporation_id of the ion that the cell wraps this +# information enables the segmentation of the tessellation and +# thus correlate per-ion properties with the volume that each cell +# represents. +# +# +# +# +# +# +# +# +# A bitmask that documents which of the cells are likely truncated because they +# share at least one face with the *aabb* of the point cloud. This field encodes the +# result of the boolean or operator applied to the value of all six wall_contact groups +# that document contact in specific outer unit normal directions of the *aabb*. +# +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the left face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# x-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the right face of *aabb*. +# Its outer unit normal points in the direction of the x-axis +# of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# y-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the rear face of *aabb*. +# Its outer unit normal points in the direction of the y-axis +# of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# z-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the direction of the z-axis of the +# *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 30496c4beb..470c947ec7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -82,3 +82,129 @@ NXapm_paraprobe_tool_common(NXobject): are used to detail the explicit affine transformations whereby one can convert representations between different reference frames. Inspect :ref:`NXtransformations` for further details. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf880b6707e5f0efa5ec615125437ad700c0b729b4877e4a230c395e2422d0df +# +# +# +# +# +# Base class documenting the information common to tools of the paraprobe-toolbox. +# +# The paraprobe-toolbox is a collection of open-source tools for performing +# efficient analyses of point cloud data where each point can represent atoms or +# (molecular) ions. A key application of the toolbox has been for research in the +# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): +# +# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ +# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ +# +# The toolbox does not replace but complements existent software tools in this +# research field. Given its capabilities of handling points as objects with +# properties and enabling analyses of the spatial arrangement of and inter- +# sections between geometric primitives, the software can equally be used +# for analyzing data in Materials Science and Materials Engineering. +# +# The common section can be used as a place to store e.g. organizational +# metadata and contextualization of that analysis in a research data +# management system. +# +# +# +# A statement whether the tool executable managed to process the analysis +# or whether this failed. Status is written to the results file after the +# end_time beyond which point in time the tool must no longer compute +# any further analysis results but exit. +# +# Only when this status message is present and its value is `success`, +# one should consider the results of the tool. In all other cases it might +# be that the tool has terminated prematurely or another error occurred. +# +# +# +# +# +# +# +# +# +# Internal identifier used by the tool to refer to an analysis (aka simulation +# id). +# +# +# +# +# The configuration file that was used to parameterize +# the algorithms that this tool has executed. +# +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis in this results file was started, +# i.e. when the respective executable/tool was started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis in this results file were +# completed and the respective process of the tool exited. +# +# +# +# +# Wall-clock time. +# +# +# +# +# +# +# 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: +# +# * paraprobe +# * 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. +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 7ce5e945f4..79c45caa8a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -160,3 +160,223 @@ NXapm_paraprobe_transcoder_results(NXobject): dimensions: rank: 1 dim: (3,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 856a4a568eaaab5878232d533f49589a6d52facb8deb2470d14e3d96f3bf269c +# +# +# +# +# +# +# +# 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. +# +# +# +# +# Total number of integers in the supplementary XDMF topology array. +# +# +# +# +# Number of entries +# +# +# +# +# Application definition for results files of the paraprobe-transcoder tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-transcoder tool is to create a standardized representation +# of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information +# to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. +# This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. +# +# So far the atom probe community has not yet agreed upon a comprehensive standardization on how to +# exchange information especially when it comes to the communication of configurations and results +# from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, +# APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document +# their origin and thus the sequence in which the file was generated during an analysis. +# +# Paraprobe-transcoder solves this limitation by interpreting the information content in such files +# and standardize the representation prior injection into the scientific data analysis tools of the toolbox. +# Therefore, the here proposed set of NeXus base classes and application definitions can be a useful +# starting point for the atom probe community to take advantage of standardized information +# exchange and improve the here proposed classes and concepts to become more inclusive. +# +# Paraprobe-transcoder uses a Python library developed based on efforts by members of the +# global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the +# actual low-level I/O operations and respective information interpretation of above-mentioned file formats. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# By default the entire reconstructed volume is processed. +# In this case, using window is also equivalent to an +# NXspatial_filter that specified a window *entire_dataset*. +# +# +# +# +# +# +# +# +# +# Mass-to-charge-state-ratio values. +# +# +# +# +# +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# Interleaved array of x, y, z positions in the specimen space. +# +# +# +# +# +# +# +# Defines in which reference frame the positions are defined. +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# Details about how peaks are interpreted as ion types or not. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml index 407cf4b677..435e105f2a 100644 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_reconstruction.yaml @@ -123,6 +123,7 @@ NXapm_reconstruction(NXprocess): unit: NX_LENGTH doc: | TODO + # results field_of_view(NX_FLOAT): unit: NX_LENGTH @@ -154,3 +155,223 @@ NXapm_reconstruction(NXprocess): here a 3d histogram of the ion is stored. Ion counts are characterized using one nanometer cubic bins without applying position smoothening algorithms during the histogram computation. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b9d8e611a7239b4bc62f3a49ee204e09c48988bed02f99b8479d34e41f5565fb +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# from which an instance of a reconstructed volume has been generated. +# These ions get new identifier assigned in the process - the so-called +# evaporation_id, which must not be confused with the pulse_id! +# +# +# +# +# Base class for the configuration and results of a (static) reconstruction algorithm. +# +# Generating a tomographic reconstruction of the specimen uses selected and +# 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. +# +# +# +# +# +# +# +# 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 this free-text field to guide how to parameterize this better in the +# future. For LEAP systems and reconstructions performed with IVAS/APSuite +# see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# +# +# +# +# CAnalysis.CSpatial.fPrimaryElement +# +# +# +# +# CAnalysis.CSpatial.fEfficiency +# +# +# +# +# CAnalysis.CSpatial.fFlightPath +# +# +# +# +# CAnalysis.CSpatial.fEvaporationField +# +# +# +# +# CAnalysis.CSpatial.fImageCompression +# +# Image compression factor (ICF) +# +# +# +# +# CAnalysis.CSpatial.fKfactor +# +# k factor +# +# +# +# +# CAnalysis.CSpatial.fRecoVolume +# +# Sum of ion volumes +# +# +# +# +# CAnalysis.CSpatial.fShankAngle +# +# Shank angle +# +# +# +# +# CAnalysis.CSpatial.fTipRadius +# +# +# +# +# CAnalysis.CSpatial.fTipRadius0 +# +# +# +# +# CAnalysis.CSpatial.fVoltage0 +# +# +# +# +# Qualitative statement about which reconstruction protocol was used. +# +# +# +# +# +# +# +# +# +# +# Different strategies for crystallographic calibration of the +# reconstruction are possible. Therefore, we collect first such +# feedback before parametrizing this further. +# +# If no crystallographic calibration was performed, the field +# should be filled with the n/a, meaning not applied. +# +# +# +# +# Tight, axis-aligned bounding box about the point cloud of the reconstruction. +# +# +# +# TODO +# +# +# +# +# TODO +# +# +# +# +# TODO +# +# +# +# +# TODO +# +# +# +# +# TODO +# +# +# +# +# TODO +# +# +# +# +# +# +# +# The nominal diameter of the specimen ROI which is measured in the +# experiment. The physical specimen cannot be measured completely +# because ions may launch but hit in locations other than the detector. +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# +# +# +# +# +# +# +# The instance of :ref:`NXcoordinate_system` +# in which the positions are defined. +# +# +# +# +# +# +# +# +# To get a first visual overview of the reconstructed dataset, +# here a 3d histogram of the ion is stored. Ion counts are characterized +# using one nanometer cubic bins without applying position smoothening +# algorithms during the histogram computation. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_simulation.yaml b/contributed_definitions/nyaml/NXapm_simulation.yaml index 433cc96620..d59a40e73e 100644 --- a/contributed_definitions/nyaml/NXapm_simulation.yaml +++ b/contributed_definitions/nyaml/NXapm_simulation.yaml @@ -1,9 +1,46 @@ category: base doc: | - Base class for documenting a simulation of removing ions from a specimen and characterizing them. + Base class for documenting a simulation of removing ions from a specimen and + characterizing them. type: group NXapm_simulation(NXobject): (NXprogram): (NXparameters): (NXprocess): (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a8dc849f90829405e50e8fb463dc764e5800f728f35e7bef62a1ac95bbf95499 +# +# +# +# +# +# Base class for documenting a simulation of removing ions from a specimen and +# characterizing them. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXatom.yaml b/contributed_definitions/nyaml/NXatom.yaml index da49385bb7..c1067f7343 100644 --- a/contributed_definitions/nyaml/NXatom.yaml +++ b/contributed_definitions/nyaml/NXatom.yaml @@ -99,7 +99,7 @@ NXatom(NXobject): dim: (n_pos,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dc696cc746aa10c9edeb6fbd31bb1237b556c0db480d5abcb79ab6e4a667d582 +# a29e115b8616c18332086bb4385318262888a3fdc41aed7e560d6b9b554bf93e # # # # +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of atom positions. +# +# +# +# +# Dimensionality +# +# +# # # Base class for documenting a set of atoms. # -# Atoms in the set may be bonded. -# The set may have a net charge to represent -# an ion. Ions can be molecular ions. +# Atoms in the set may be bonded. The set may have +# a net charge to represent an ion. +# Ions can be molecular ions. # # # # Given name for the set. # # This field could for example be used in the research field -# of atom probe tomography for storing a standardized -# human-readable name of the element or (molecular) ion -# like such as Al +++ or 12C +. +# of atom probe tomography to store a standardized human-readable +# name of the element or (molecular) ion like such as Al +++ or 12C +. # # # @@ -180,7 +194,6 @@ NXatom(NXobject): # that is unique as a some cut-off criterion is required. # # -# # # # Index for each atom at locations as detailed by position. @@ -194,8 +207,8 @@ NXatom(NXobject): # # Nuclide information for each atom at locations as detailed by position. # -# One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information efficiently -# is via hashing with the following formula +# One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information +# efficiently is via hashing with the following formula # # :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` # diff --git a/contributed_definitions/nyaml/NXcg_hexahedron.yaml b/contributed_definitions/nyaml/NXcg_hexahedron.yaml index da1d3ffd7f..83ed4bd90f 100644 --- a/contributed_definitions/nyaml/NXcg_hexahedron.yaml +++ b/contributed_definitions/nyaml/NXcg_hexahedron.yaml @@ -146,3 +146,197 @@ NXcg_hexahedron(NXcg_primitive): nameType: partial doc: | Individual storage of each hexahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9a91e731a011f357acdd1310cdece4aa43a4ec09ec35774d98505a570d5e986d +# +# +# +# +# +# +# +# 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. +# +# 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 an approach whereby +# different specific views can be implemented using the same base class: +# +# * In the simplest case experimentalists may use this base class to describe +# the dimensions or size of a specimen. In this case the alignment with axes +# is not relevant as eventually only the volume of the specimen is of interest. +# * In many cases, take for example an experiment where a specimen was cut out +# from a specifically deformed piece of material, the orientation of the +# specimen's edges with the experiment coordinate system is of high relevance. +# Examples include knowledge about the specimen edge, whether it is +# parallel to the rolling, the transverse, or the normal direction. +# * While the above-mentioned use cases are sufficient to pinpoint the sample +# within a known laboratory/experiment coordinate system, these descriptions +# are not detailed enough to specify e.g. a CAD model of the specimen. +# * Therefore, groups and fields for an additional, computational-geometry- +# based view of hexahedra is offered to serve additional 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. +# +# As a specialization of the :ref:`NXcg_primitive` base class hexahedra +# are assumed non-degenerated, closed, and built of polygons that are +# not self-intersecting. +# +# The term hexahedra will be used throughout this base class but includes +# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), +# and optimal bounding box (OBB). +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a cuboid whose edges are aligned with the +# base vectors of a coordinate system. As a part of binary trees, these data +# objects are important for making 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 +# tightly fitting box about an arbitrary object. In general, such boxes are +# rotated. Exact and substantially faster in practice approximate algorithms +# exist to compute optimal or near optimal bounding boxes for sets of points. +# +# +# +# +# Qualifier for the shape of each hexahedron. +# +# +# +# +# +# +# +# +# Qualifier that is useful in cases when one edge is longer than all other +# edges of the hexahedra. Often the term length is associated with the +# assumption that one edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the horizontal +# direction assuming a specific coordinate system. +# +# For the sake of explicitness quantities like length, width, and height +# should not be reported without specifying also the assumed reference frame. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the vertical +# direction assuming a specific coordinate system. +# +# +# +# +# +# +# +# Volume of each hexahedron. +# +# +# +# +# +# +# +# Total (surface) 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 coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all hexahedra. +# +# +# +# +# Individual storage of each hexahedron. +# +# +# +# +# Individual storage of each hexahedron as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram.yaml b/contributed_definitions/nyaml/NXcg_parallelogram.yaml index 2e90b0787b..3e9b791569 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram.yaml +++ b/contributed_definitions/nyaml/NXcg_parallelogram.yaml @@ -66,3 +66,107 @@ NXcg_parallelogram(NXcg_primitive): nameType: partial doc: | Individual storage of each parallelogram. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 925993111384a8a2e209475675f51f560114d21c32b9ed50c5f4f8db413a87af +# +# +# +# +# +# +# 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. +# +# This class can also be used to describe rectangles or squares, irrespective +# whether these are axis-aligned or not. The class represents different +# access and description levels to embrace applied scientists and computational +# geometry experts with their different views: +# +# * The simplest case is the communication of dimensions aka the size of a +# region of interest in the 2D plane. In this case, communicating the +# alignment with axes is maybe not as relevant as it is to report the area +# of the ROI. +# * In other cases the extent of the parallelogram is relevant though. +# * Finally, in CAD models it should be possible to specify the polygons +# which the parallelograms represent with exact numerical details. +# +# Parallelograms are important geometrical primitives as their usage for +# describing many scanning experiments shows where typically parallelogram-shaped +# ROIs are scanned across the surface of a sample. +# +# The term parallelogram will be used throughout this base class thus including +# the important special cases rectangle, square, 2D box, axis-aligned bounding box +# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D +# counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a rectangle whose edges are aligned with the +# axes of a coordinate system. As a part of binary trees AABBs are important data +# objects for executing 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, i.e. +# most tightly 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 an optimal bounding box to a point set in 2D. +# +# +# +# +# To specify which parallelogram is a rectangle. +# +# +# +# +# +# +# +# Only to be used if is_rectangle is present. In this case, this field +# describes whether parallelograms are rectangles whose primary edges +# are parallel to the axes of the coordinate system. +# +# +# +# +# +# +# +# +# Combined storage of all parallelograms. +# +# +# +# +# Individual storage of each parallelogram. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polygon.yaml b/contributed_definitions/nyaml/NXcg_polygon.yaml index 4af45fe7da..4a2c92058a 100644 --- a/contributed_definitions/nyaml/NXcg_polygon.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon.yaml @@ -52,9 +52,10 @@ NXcg_polygon(NXcg_primitive): doc: | Individual storage of the mesh of each polygon. polygon_half_edgeID(NXcg_half_edge_data_structure): - nameType: any + nameType: partial doc: | Individual storage of each polygon as a graph. + # properties of the polygon primitives edge_length(NX_NUMBER): unit: NX_LENGTH @@ -85,3 +86,132 @@ NXcg_polygon(NXcg_primitive): dimensions: rank: 1 dim: (c,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3ab4f90cb7af6c4ca0eb76b2b98d21d3f57e7720a90cef38a0d4577acd99bf20 +# +# +# +# +# +# +# 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed +# polyhedra. Even more general complexes can be thought of. An example are the +# so-called piecewise-linear complexes used in the TetGen library. +# +# As these complexes 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 to describe such even more complex primitives instead +# of abusing this base class for such purposes. +# +# +# +# The total number of vertices in the set. +# +# +# +# +# +# Combined storage of all primitives of all polygons. +# +# +# +# +# Individual storage of the mesh of each polygon. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# +# +# +# For each polygon its accumulated length along its edges. +# +# +# +# +# +# +# +# Interior angles for each polygon. There are as many values per polygon +# as the are 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 +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron.yaml b/contributed_definitions/nyaml/NXcg_polyhedron.yaml index 608ab74bb7..ef06d70805 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron.yaml @@ -71,3 +71,120 @@ NXcg_polyhedron(NXcg_primitive): nameType: partial doc: | Individual storage of each polygon as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2268cd65f210df7756fba0491d0e970f7155b246640a0695d05778ef3de5ee93 +# +# +# +# +# +# +# +# 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 set of polyhedra in Euclidean space. +# +# Polyhedra or so-called cells (especially in the convex of tessellations) are +# constructed from polygon meshes. Polyhedra may make contact to allow a usage +# of this base class for a description of tessellations. +# +# For the description of more complicated manifolds and especially for polyhedra +# with holes, users are advised to check if their particular needs are described +# by creating customized instances of an :ref:`NXcg_polygon`. +# +# +# +# +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. +# +# +# +# +# +# +# +# Area of each of faces. +# +# +# +# +# +# +# +# The number of edges for each polyhedron. Edges of adjoining polyhedra +# are counted for each polyhedron. +# +# +# +# +# Length of each edge. +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all polyhedra. +# +# +# +# +# Individual storage of each polyhedron. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_roi.yaml b/contributed_definitions/nyaml/NXcg_roi.yaml index 0ae444def0..76b7f1c336 100644 --- a/contributed_definitions/nyaml/NXcg_roi.yaml +++ b/contributed_definitions/nyaml/NXcg_roi.yaml @@ -8,8 +8,10 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes - to define explicitly the reference frame in which the primitives are defined. + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to + define explicitly the reference frame in which the primitives are + defined. + # eventually redundant NXsolid_geometry? type: group NXcg_roi(NXobject): @@ -21,3 +23,55 @@ NXcg_roi(NXobject): # how to handle cases where multiple primitives should be included? # see comment to NXcg_triangle roi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3227a9f16fd3ed1e325ec7ccb157fea7397a3855d2664809641eff45bd83caad +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to +# define explicitly the reference frame in which the primitives are +# defined. +# +# +# +# Base class for a region-of-interest (ROI) bound by geometric primitives. +# +# So-called region-of-interest(s) (ROIs) are typically used to describe a +# region in space (and time) where an observation is made or for which +# a computer simulation is performed with given boundary conditions. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron.yaml index 436a09b09d..af0f62cef7 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron.yaml @@ -36,6 +36,85 @@ NXcg_tetrahedron(NXcg_primitive): doc: | Individual storage of each tetrahedron. tetrahedron_half_edgeID(NXcg_half_edge_data_structure): - nameType: any + nameType: partial doc: | Individual storage of each tetrahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c30eb2a185c58585e687170725c1eec1cba75c937b6699dbdd01ee1272542618 +# +# +# +# +# +# +# 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. +# +# Among hexahedral elements, tetrahedral elements are one of the most +# frequently used geometric primitive for meshing and describing volumetric +# objects in continuum-field simulations. +# +# +# +# +# Area of each of the four triangular faces of each tetrahedron. +# +# +# +# +# +# +# +# +# Length of each edge of each tetrahedron. +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all tetrahedra. +# +# +# +# +# Individual storage of each tetrahedron. +# +# +# +# +# Individual storage of each tetrahedron as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_triangle.yaml b/contributed_definitions/nyaml/NXcg_triangle.yaml index 53ab5d4af0..5637294d91 100644 --- a/contributed_definitions/nyaml/NXcg_triangle.yaml +++ b/contributed_definitions/nyaml/NXcg_triangle.yaml @@ -48,3 +48,98 @@ NXcg_triangle(NXcg_primitive): dimensions: rank: 2 dim: (c, 3) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fe99956b8b305e0e920fc7b726b5f8ed243fefa82c6ebb87f13e1ce8cdebef9d +# +# +# +# +# +# +# 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. +# +# +# +# Number of unique vertices in the triangle set. +# +# +# +# +# Combined storage of all primitives of all triangles. +# +# This description resembles the typical representation of primitives +# in file formats such as OFF, PLY, VTK, or STL. +# +# +# +# +# Individual storage of each triangle. +# Users are advised that using such individual storage of primitives +# may be less storage efficient than creating a combined storage. +# +# +# +# +# Length of the edges of each triangle. +# +# For each triangle values are reported via traversing +# the vertices in the sequence as these are defined. +# +# +# +# +# +# +# +# +# Interior angles of each triangle. +# +# For each triangle values are reported for the angle opposite +# to the respective edges in the sequence how vertices are defined. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 10531ce484..f7b5eb457f 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -46,6 +46,7 @@ NXcircuit(NXcomponent): unit: NX_FREQUENCY doc: | The bandwidth of the frequency response of the circuit. + # we may need an NX_RESISTANCE defined input_impedance(NX_NUMBER): unit: NX_ANY @@ -105,7 +106,7 @@ NXcircuit(NXcomponent): value. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0354df665f0472e82c72fe2a66dc6d31749f36bfc9d1ac2302192f406d297b75 +# 618f030e81428fff01c66c2a4af66d1697e51dd87d955b2a63f08628a6c316ff # # # # # -# The operating frequency of the circuit, see also bandwidth below, which is possibly -# centered around this frequency. However, not necessarily (e.g. running a 100 kHz bandwidth -# amplifier at low, audio frequencies 1 - 20,000 Hz) +# The operating frequency of the circuit, see also bandwidth, which is possibly +# but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth +# amplifier at low, audio frequencies 1 - 20,000 Hz). +# +# +# +# +# The bandwidth of the frequency response of the circuit. # # # @@ -200,18 +206,14 @@ NXcircuit(NXcomponent): # # # -# Gain of the circuit, if applicable, usually all instruments have a gain which might be -# important or not. +# Gain of the circuit, if applicable, usually all instruments have a gain +# which might be important or not. # # # # -# RMS noise level (in current or voltage) in the circuit in voltage or current. -# -# -# -# -# The bandwidth of the frequency response of the circuit. +# Root-mean-square (RMS) noise level (in current or voltage) +# in the circuit in voltage or current. # # # @@ -244,7 +246,7 @@ NXcircuit(NXcomponent): # Power consumption of the circuit per unit time. # # -# +# # # Status indicators for the circuit, e.g., LEDs, display readouts. # diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index ba80567602..e7fbf15209 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -93,3 +93,154 @@ NXcoordinate_system(NXobject): doc: | Collection of axis-based translations and rotations to describe this coordinate system with respect to another coordinate system. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f5857b78fc7a477daa58ac7f3a1b1fe8fa1e95b7abe12af3fc97c97b0f9f4665 +# +# +# +# +# +# Base class to detail a coordinate system (CS). +# +# +# +# Human-readable field telling where the origin of this CS is. +# Exemplar values could be *left corner of the lab bench*, *door-handle* +# *pinhole through which the electron beam exists the pole piece*. +# *barycenter of the triangle*, *center of mass of the stone*. +# +# +# +# +# +# An alternative name given to that coordinate system. +# +# +# +# +# Coordinate system type. +# +# +# +# +# +# +# +# Handedness of the coordinate system if it is a Cartesian. +# +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the x-axis. +# +# +# +# +# Human-readable field telling in which direction the x-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent +# and as such is the world reference frame. +# +# Exemplar values could be direction of gravity. +# +# +# +# +# +# Base unit vector along the first axis which spans the coordinate system. +# This axis is frequently referred to as the x-axis in real space and +# the i-axis in reciprocal space. +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the y-axis. +# +# +# +# +# Human-readable field telling in which direction the y-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent +# and as such is the world reference frame. +# +# See docstring of x_alias for further details. +# +# +# +# +# Base unit vector along the second axis which spans the coordinate system. +# This axis is frequently referred to as the y-axis in real space and +# the j-axis in reciprocal space. +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the z-axis. +# +# +# +# +# Human-readable field telling in which direction the z-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent +# and as such is the world reference frame. +# +# See docstring of x_alias for further details. +# +# +# +# +# Base unit vector along the third axis which spans the coordinate system. +# This axis is frequently referred to as the z-axis in real space and +# the k-axis in reciprocal space. +# +# +# +# +# +# +# +# This specifies the relation to another coordinate system by pointing to the last +# transformation in the transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe this coordinate system +# with respect to another coordinate system. +# +# +# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 59e26c23eb..fe6cecb51e 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -17,7 +17,6 @@ doc: | * Use :ref:`NXcorrector_cs` for spherical aberration * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration - symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -25,6 +24,7 @@ symbols: Number of images taken, at least one. type: group NXcorrector_cs(NXcomponent): + # user perspective applied(NX_BOOLEAN): doc: | @@ -131,7 +131,7 @@ NXcorrector_cs(NXcomponent): (NXdeflector): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 11774a67983a09f8285597de90c4ff62b52b18b2e82462a4964c47668bc582f7 +# 6058db5121e6633ea3ec355f79d43ab1ee54bf298dd8945d3f0746dd51a5af33 # # # -# # # # @@ -174,12 +172,14 @@ NXcorrector_cs(NXcomponent): # Different technology partners use different conventions and # models for quantifying the aberration coefficients. # -# The corrector in an electron microscope is composed of multiple lenses -# and multipole stigmators with details that are specific for the technology partner -# and microscope. Most technical details are proprietary knowledge. +# Correctors in an electron microscope are composed of multiple lenses +# and multipole stigmators. Their technical details are specific for the +# technology partner as well as microscope. Most technical details are +# proprietary knowledge. # -# If one component corrects for multiple types of aberrations (like it is the case reported -# here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this design: +# If one component corrects for multiple types of aberrations (like it is the case +# reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this +# design when using corrector and monochromator in an application definition: # # * Use :ref:`NXcorrector_cs` for spherical aberration # * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration @@ -191,9 +191,9 @@ NXcorrector_cs(NXcomponent): # Was the corrector used? # # -# +# # -# Specific information about the alignment procedure that is a process during which +# Specific information about the alignment procedure. This is a process during which # the corrector is configured to enable calibrated usage of the instrument. # # This :ref:`NXprocess` group should also be used when one describes in a computer @@ -210,7 +210,8 @@ NXcorrector_cs(NXcomponent): # The outer tilt angle of the beam in tableau acquisition. # # TODO: The relevant axes which span the tilt_angle need a -# cleaner description. +# cleaner description. Suggestions from the community are +# welcome here for guiding an improvement of this base class. # # # @@ -233,14 +234,14 @@ NXcorrector_cs(NXcomponent): # # # -# +# # # Image(s) taken during the alignment procedure # # # # -# Convention used for storing measured or estimated aberrations (for each image or final) +# Convention used for storing measured or estimated aberrations (for each or the final image) # via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. # # See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) @@ -296,45 +297,6 @@ NXcorrector_cs(NXcomponent): # # # -# # # # diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 10fa91a008..3ef6c163db 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -24,4 +24,64 @@ NXcs_computer(NXobject): the Universally Unique Identifier (UUID) of the computing node. (NXcs_process): (NXcs_memory): - (NXcs_storage): \ No newline at end of file + (NXcs_storage): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f8c3423ab012d77662d765c69bbf7280b87d75a6434e336d4951c58ef9174601 +# +# +# +# +# +# Base class for reporting the description of a computer +# +# +# +# Given name/alias to the computing system, e.g. MyDesktop. +# +# +# +# +# Name of the operating system, e.g. Windows, Linux, Mac, Android. +# +# +# +# Version plus build number, commit hash, or description of an ever +# persistent resource where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# +# A globally unique persistent identifier of the computer, i.e. +# the Universally Unique Identifier (UUID) of the computing node. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_memory.yaml b/contributed_definitions/nyaml/NXcs_memory.yaml index a166352198..dffa6c6d9b 100644 --- a/contributed_definitions/nyaml/NXcs_memory.yaml +++ b/contributed_definitions/nyaml/NXcs_memory.yaml @@ -14,3 +14,50 @@ NXcs_memory(NXcomponent): unit: NX_ANY doc: | Total amount of data which the medium can hold. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 03f38cfd71b4b756cf9fc6db35a038a594dde358af5da47d2b5ce3737ca1bd80 +# +# +# +# +# +# Base class for reporting the description of the memory system of a computer. +# +# +# +# +# Qualifier for the type of random access memory. +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_process.yaml b/contributed_definitions/nyaml/NXcs_process.yaml index 87d14283d9..8cdc6f54a4 100644 --- a/contributed_definitions/nyaml/NXcs_process.yaml +++ b/contributed_definitions/nyaml/NXcs_process.yaml @@ -15,10 +15,64 @@ NXcs_process(NXcomponent): * A server with two dual-socket server nodes; describe with four instances of NXcircuit surplus a field that defines their level in the hierarchy. - type(NX_CHAR): doc: | General type of the processing unit enumeration: - open_enum: true - items: [cpu, gpu, fpga] + open_enum: true + items: [cpu, gpu, fpga] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e63846fc37f720e00d319289435e1f4f1869f2632b2c0db2ebe3196dcad64689 +# +# +# +# +# +# Base class for reporting the description of processing units of a computer. +# +# Examples are e.g. (classical) processing units (CPUs), coprocessor, +# graphic cards, accelerator processing units or a system of these. +# +# +# +# Typical examples for the granularization of processing units are: +# +# * A desktop computer with a single CPU; describe using one instance of NXcircuit. +# * A dual-socket server; describe using two instances of NXcircuit. +# * A server with two dual-socket server nodes; describe with four +# instances of NXcircuit surplus a field that defines their level +# in the hierarchy. +# +# +# +# General type of the processing unit +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_storage.yaml b/contributed_definitions/nyaml/NXcs_storage.yaml index b4ce472a8b..9c1d812415 100644 --- a/contributed_definitions/nyaml/NXcs_storage.yaml +++ b/contributed_definitions/nyaml/NXcs_storage.yaml @@ -12,3 +12,51 @@ NXcs_storage(NXcomponent): unit: NX_ANY doc: | Total amount of data which the medium can hold. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 23d6eaded2f856c501322359c37f1cf51f34300d2feed62f65334296a430b5c5 +# +# +# +# +# +# Base class for reporting the description of the I/O of a computer. +# +# +# +# +# Qualifier for the type of storage medium used. +# +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index d9c8401afb..f3859c9eb1 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -185,3 +185,244 @@ NXebeam_column(NXcomponent): term: Electron Beam url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 (NXcomponent): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1a0b8cfa31f7ddb34bf2c8001383fd77768103af9b0be227befcde88466d3c8e +# +# +# +# +# +# Base class for a set of components providing a controllable electron beam. +# +# The idea behind defining NXebeam_column as an own base class vs. adding these +# concepts in NXinstrument_em is that the electron beam generating component +# might be worthwhile to use also in other types of experiments. +# +# +# +# Tech-partner, microscope-, and control-software-specific name of the +# specific operation mode how the ebeam_column and its components are +# controlled to achieve specific illumination conditions. +# +# In many cases the users of an instrument do not or can not be expected to know +# all intricate spatiotemporal dynamics of their hardware. Instead, they rely on +# assumptions that the instrument, its control software, and components work as +# expected to focus on their research questions. +# +# For these cases, having a place for documenting the operation_mode is useful +# in as much as at least some constraints on how the illumination conditions were +# is documented. +# +# +# +# +# A physical part of an electron or ion microscope from which +# the particles that form the beam are emitted. +# +# The hardware for an electron source in an electron microscope +# may contain several components which affect the beam path. +# +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# +# +# +# The potential difference between anode and cathode. +# +# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. +# +# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 +# +# +# +# +# Voltage which is used to create an electric field that draws particles from +# the source. +# +# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. +# +# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which is released from the source. +# +# This concept is related to term `Emission Current`_ of the EMglossary standard. +# +# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which flows through the source. +# +# This concept is related to term `Filament Current`_ of the EMglossary standard. +# +# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 +# +# +# +# +# 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. +# +# +# +# +# +# How long has the source been in operation. +# +# +# +# +# +# +# +# +# A component for blanking the beam or generating pulsed electron beams. +# See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ +# or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. +# +# +# +# +# Device to improve energy resolution or chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# +# +# +# +# Qualitative type of the component. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Was the corrector used? +# +# +# +# +# +# Energy dispersion in e.g. µm/eV. +# +# +# +# +# Corresponding voltage for that energy dispersion. +# +# +# +# +# +# +# Component that reshapes an ellipse-shaped electron beam into a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. +# +# +# +# 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 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 users. +# +# +# +# +# +# Electron biprism as it is used e.g. for electron holography. +# +# +# +# +# Device that causes a change in the phase of an electron wave. +# +# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ +# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ +# +# +# +# Qualitative type +# +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the electron beam at a given location. +# +# :ref:`NXtransformations` should be used to specify the location +# or the position at which details about the beam were probed. +# +# This concept is related to term `Electron Beam`_ of the EMglossary standard. +# +# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index da6ba1fe7d..acea2d1a70 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -40,8 +40,6 @@ NXem(NXobject): from conda or python virtualenv environments. program(NX_CHAR): \@version(NX_CHAR): - - identifier_experiment(NX_CHAR): exists: optional doc: | @@ -576,6 +574,7 @@ NXem(NXobject): nameType: partial exists: ['min', '0', 'max', 'unbounded'] deflectorID(NXdeflector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] ibeam_column(NXibeam_column): exists: ['min', '0', 'max', '1'] @@ -700,6 +699,7 @@ NXem(NXobject): exists: recommended identifier_sample(NX_CHAR): exists: recommended + # above field is another example for lacking support to define conditional existence constraints imageID(NXimage): exists: ['min', '0', 'max', 'unbounded'] @@ -1035,7 +1035,8 @@ NXem(NXobject): 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 users. - # NXaperture/size can be used as a fallback + + # NXaperture/size can be used as a fallback monochromatorID(NXmonochromator): nameType: partial exists: ['min', '0', 'max', 'unbounded'] @@ -1231,6 +1232,7 @@ NXem(NXobject): nameType: partial exists: ['min', '0', 'max', 'unbounded'] deflectorID(NXdeflector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] detectorID(NXdetector): nameType: partial @@ -1318,8 +1320,7 @@ NXem(NXobject): roiID(NXroi): nameType: partial exists: ['min', '0', 'max', 'unbounded'] - doc: - - | + doc: | xref: spec: EMglossary term: Region Of Interest @@ -1503,3 +1504,1588 @@ NXem(NXobject): # see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 434eb9b819d62bf4c4232ffe882c157f61c386a61070dc237fd860af4e2ff5c4 +# +# +# +# +# +# Application definition for normalized representation of electron microscopy research. +# +# This application definition is a comprehensive, general description for the +# standardization of data and metadata collected using electron microscopy. +# +# NXem is designed to be used for documenting experiments or computer simulations in which +# controlled electron beams are used to study electron-beam matter interactions, explore +# physical mechanisms and phenomena, or to characterize materials with an electron microscope. +# +# +# +# +# +# +# +# +# +# The configuration of the software that was used to generate this NeXus file. +# +# +# +# A collection of all programs and libraries used to generate this NeXus file. +# Ideally, this would enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific set +# of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# Instances can also be used to document the modules and libraries that +# are offered by the computational environment such as those parsed +# from conda or python virtualenv environments. +# +# +# +# +# +# +# +# +# A (globally) unique persistent identifier for referring to this experiment. +# +# +# +# +# Alias (short name) which scientists can use to refer to this experiment. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into the 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 - use this start_time field. +# +# Often though it is useful to specify a time interval via setting both a start_time +# and an end_time because this enables software tools and users to collect a +# more detailed bookkeeping of the experiment. +# +# Users should be aware though that even using only start_time and end_time +# may not be sufficient to infer how long the experiment took or for how long +# data were acquired. To bookkeep more fine-grained timestamps over the +# course of the experiment is possible with start_time and end_time fields +# of respective :ref:`NXevent_data_em` instances. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included when +# the microscope session ended. +# +# See docstring of the start_time field to see how to use the +# start_time and end_time together. +# +# +# +# +# +# Collection of serialized resources associated with the experiment. +# Examples of such resources are files which are formatted using proprietary +# data models of technology partners as those generated by the control software +# of the microscope during the instrument session. +# +# +# +# +# +# +# +# +# Information about persons who performed or were involved in the microscope +# session or simulation run. +# +# +# +# +# +# +# Given (first) name and surname. +# +# +# +# +# Name of the affiliation at the point in time when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address at the point in time when the experiment was performed. +# +# Writing the most permanently used email is recommended. +# +# +# +# +# Telephone number at the point in time when the experiment was performed. +# +# +# +# +# User role at the point in time when the experiment was performed. +# +# Examples are technician operating the microscope, student, postdoc, +# principle investigator, or guest. +# +# +# +# +# +# A physical entity which contains material intended to be investigated. +# Sample and specimen are treated as de facto synonyms. +# Samples can be real or virtual ones as annotated via is_simulation. +# +# The suggested best practice is to call this group sample. In those cases when +# multiple samples need to be grouped inside one entry, these SAMPLE groups +# should be named using the prefix sample followed an index starting from 1, i.e. +# (sample1, sample2). +# +# There are at least two strategies how to store (meta)data when one analyzes multiple +# samples - not different ROIs on a single sample though - in one session. +# +# One strategy is to store each sample and its results under an own NXem/ENTRY. +# This is one of the most frequent use cases as during most sessions typically only a +# single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. +# +# If multiple samples are investigated storing each of them in their own ENTRY group eventually will +# demand unnecessary duplication of instrument details. +# +# This can be avoided by using another strategy for storing samples and their results. +# Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, +# like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., +# i.e. instances should use sample as a name prefix. +# +# In this case the collection of events should use identifier_sample to state clearly for which +# of the samples loaded the (characterization) event was detected. +# +# This concept is related to term `Specimen`_ of the EMglossary standard. +# +# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 +# +# +# +# Qualifier whether the sample is a real (in which case is_simulation should be set to false) +# or a virtual one (in which case is_simulation should be set to true). +# +# +# +# +# +# +# +# +# +# +# +# +# Ideally, (globally) unique persistent identifier which distinguishes this sample from all others +# and especially the predecessor/origin from where that sample was cut off. An example of cutting off +# is a steel sheet that is the parent sample from which a small portion was wire-eroded that +# represents the sample that was then prepared for characterization with an electron microscope. +# +# The terms sample and specimen are here considered as exact synonyms. +# +# This field must not be used for an alias for the sample name. Instead, use name. +# +# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve +# the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single +# NXentry should be used for the characterization of a single specimen. +# +# Details about the specimen preparation should be stored in resources referring to identifier_parent. +# +# +# +# +# +# Identifier of the sample from which the sample was cut off or the string *None*. +# I.e. the parent to this sample. +# +# The purpose of this field is to support functionalities for tracking +# sample provenance in a research data management system. +# +# +# +# +# +# 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 timestamp when +# the measured specimen surface was actively prepared. Ideally, this matches +# the last timestamp that is mentioned in the digital resource pointed to by +# identifier_parent. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is especially +# required for material that is sensitive to the environment such as specimens that were +# charged with fast diffusing elements or short-lived radioactive tracers. +# +# Additional time stamps prior to preparation_date are better placed in resources which +# describe but do not pollute the description here with prose. Resolving these +# connected metadata is considered the responsibility of the research data management +# system and not the a NeXus file. +# +# +# +# +# Specimen name +# +# +# +# +# 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 research data management systems an opportunity +# to parse the relevant elements without having to interpret these from the resources +# pointed to by identifier_parent or walk through eventually deeply nested groups in +# individual data instances. +# +# +# +# +# (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 typically 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 a +# region-of-interest connected to individual :ref:`NXevent_data_em` +# instances can provide a cleaner description of the relevant details. +# +# +# +# +# Discouraged free-text field to provide further detail. +# +# +# +# +# +# The conventions used when reporting crystal orientations. +# We follow the best practices of the Material Science community +# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin. +# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) +# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge +# but other conventions are possible. Apart from undefined, proper Euler angles +# are distinguished from (improper) Tait-Bryan angles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parametrizations/representations according +# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Location of the origin of the processing_reference_frame. +# +# It is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the specifically named :ref:`NXsample` instance(s) for +# which these conventions apply (e.g. /entry1/sample1). +# +# +# +# +# +# +# +# Location of the origin of the sample_reference_frame. +# +# It is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The reference frame that is defined by a specific detector. +# +# +# +# Reference to the specifically named :ref:`NXdetector` instance for +# which these conventions apply (e.g. /entry1/instrument/detector1). +# +# +# +# +# +# +# +# Location of the origin of the detector_reference_frame. +# +# If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the control program used for operating the microscope. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptor for the aperture setting 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 users. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptor for the aperture setting 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 users. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Operation mode of the detector as displayed by the control software. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Nominal current of the heater. +# +# +# +# +# Nominal voltage of the heater. +# +# +# +# +# +# +# +# +# +# +# +# Documentation for a simulation of electron beam-matter interaction. +# +# +# +# The program with which the simulation was performed. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# Configuration of the simulation +# +# +# +# +# Results of the simulation +# +# +# +# +# +# +# +# +# +# +# +# +# This concept is related to term `Region Of Interest`_ of the EMglossary standard. +# +# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index b8061ae358..5c8a8f0dda 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -239,3 +239,303 @@ NXem_calorimetry(NXobject): background_subtraction(NXprocess): exists: optional sequence_index(NX_POSINT): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4142f89f3701f4bac98d8ae1a748b84cd7cd9e234abf03c755544e7decfa229a +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of diffraction pattern. +# +# +# +# +# Number of radial integration bins. +# +# +# +# +# Number of coordinates along i axis. +# +# +# +# +# Number of coordinates along j axis. +# +# +# +# +# Application definition for minimal example in-situ calorimetry. +# +# TODO: +# +# * What is the technique about. +# * General context. +# * Literature references. +# +# +# +# +# +# +# +# +# +# +# Details about performance, profiling, etc. +# +# +# +# +# +# +# +# Name of the program whereby this config file was created. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# Qualifier whether the sample is a real (in which case is_simulation should be set to false) +# or a virtual one (in which case is_simulation should be set to true). +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources. +# +# +# +# +# +# +# +# +# Reference to the resource which stores acquired pattern from the +# experiment or simulation that are analyzed in this workflow. +# +# Can refer to the original EMD or MRC files or the parsed NXem +# in RDM e.g. NOMAD OASIS. +# +# +# +# +# +# +# +# Reference to the resource which stores actuator log file from the experiment. +# +# +# +# +# +# +# +# Configuration file that was used for parametrizing this analysis workflow. +# +# +# +# +# +# +# +# Assumptions and computations whereby timestamping data from +# the detector and actuator (e.g. heating chip) were synchronized. +# +# +# +# +# ISO8601 with local time zone reference timestamp that tells +# with which delta_time can be converted in timestamp. +# The reference timestamp is defined as the time when the +# actuator started acting on the sample. +# +# Time differences to this timestamp when correlated signals such +# as diffraction pattern matching with a specific state of the sample +# (e.g. obtained temperature via the actuator) are reported through +# delta_time. +# +# +# +# +# +# +# +# +# +# Time difference to start_time. +# +# Collecting diffraction pattern also takes some time. +# It is assumed that the acquisition time for each pattern is +# substantial shorter than the time it takes the actuator to +# cause a change in stimulus (e.g. temperature). +# +# +# +# +# +# +# +# +# +# Computation of the center for each pattern using e.g. a Circular Hough +# Transformation. +# +# +# +# +# +# Computed center for each pattern. +# +# +# +# +# +# +# +# +# +# +# Elliptical distortion correction as a step when computing the center for +# patterns. +# +# +# +# +# +# Computed center for each pattern. +# +# +# +# +# +# +# +# +# +# +# Integrated diffraction pattern intensity as a function of radial distance from the center +# azimuthally integrated as a function of time. +# +# +# +# +# +# The integrated intensities: +# +# * result_with_background +# * result_without_background +# +# +# +# +# +# +# +# Integrated intensity as a function of time and the radial distance from the +# pattern center. +# +# +# +# +# +# +# +# +# +# Identifier for each pattern. +# +# +# +# +# +# +# +# +# Positions in reciprocal space. +# +# +# +# +# +# +# +# +# +# Time since start of the in-situ experiment +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 0f371f5df4..6d1933ac44 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -495,3 +495,684 @@ NXem_ebsd(NXprocess): \@long_name(NX_CHAR): doc: | Label for the x axis + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 82a3639815330347d1689d9057a7881b35944b189b49d76b005137bc07062ade +# +# +# +# +# +# +# +# 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 plot orientation mapping. +# +# +# +# +# Number of pixel along slow changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of pixel along fast changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of phase solutions +# +# +# +# +# Number of reflectors (Miller crystallographic plane triplets). +# +# +# +# +# Base class method-specific for Electron Backscatter Diffraction (EBSD). +# +# The general procedure of an EBSD experiment is as follows: +# Users load the specimen, collect first a coarse image of the surface. +# Next, they set an approximate value for the calibrated working distance +# and tilt the stage into diffraction conditions. +# +# Users then typically configure the microscope for collecting quality data. +# The EBSD detector is pushed in (if retractable). Subsequently, they fine tune +# the illumination and aberration corrector settings and select one or multiple ROIs +# for the microscope to machine off automatically. They configure on-the-fly +# indexing parameter and then typically start the measurement queue. +# From this point onwards typically the microscope runs automatically. +# +# Diffraction pattern get collected until the queue finishes or gets interrupted by +# either errors or arrival at the end of the users' allocated timeslot at the instrument. +# +# Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. +# Once indexed, these patterns are often not stored. +# +# Results are stored in files, which afterwards are typically copied +# automatically or manually for archival purposes to certain storage +# locations for further consumption. The result of such an EBSD +# measurement/experiment is a set of usually proprietary or open files +# from technology partners. +# +# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific +# data, metadata, and connections between these for the research field of +# electron microscopy exemplified here for electron backscatter diffraction (EBSD). +# The base class solves two key documentation issues within the EBSD community: +# +# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted +# according to NXem_ebsd) stores the connection between the microscope session and +# the key datasets which are considered typically results of the afore-mentioned +# steps involved in an EBSD experiment. +# +# Different groups in NXem_ebsd make connections to data artifacts which were collected +# when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, +# associated overview images, like secondary electron or backscattered electron +# images of the region-of-interest probed, and many more (meta)data. +# +# Secondly, NXem_ebsd connects and stores the conventions and reference frames +# which were used and which are the key to a correct mathematical interpretation +# of every experiment or simulation using EBSD. +# +# Otherwise, results would be ripped out of their context like it is the current situation +# with many traditional studies where EBSD data were indexed on-the-fly and shared +# with the community only via sharing the strongly processed files with results in some +# formatting but without communicating all conventions used or just relying on the assumptions +# that colleagues likely know these conventions even though +# multiple definitions are possible. +# +# NXem_ebsd 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) experiments +# where a combination of repetitive removal of material from the surface layer to measure +# otherwise the same region-of-interest at different depth increments. Material removal +# can be achieved with mechanical, electron, or ion polishing, using manual steps or +# automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. +# +# Three-dimensional experiments require to follow a sequence of specimen, surface +# preparation, and data collection steps. By virtue of design, these methods are destructive +# either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. +# +# Eventual tomography methods also use such a workflow because first diffraction +# images are collected (e.g. with X-ray) and then these images are indexed to process +# a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint +# also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. +# +# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. +# +# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 +# +# +# +# Details about the gnomonic (projection) reference frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions are not met, the user is required to explicitly state this. +# +# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the +# base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. +# +# +# +# Origin of the gnomonic_reference_frame. +# +# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to +# assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the definition of the pattern center as a special point in the +# gnomonic_reference_frame. +# +# Typically the gnomonic space is embedded in the detector space. +# Specifically, the XgYg plane is defined such that it is 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 +# one effectively normalizes in fractions of the width of the detector. +# +# The issue with terms like width and height, though, is that these become degenerated +# if the detector region-of-interest is square-shaped. This is why instead of referring to +# width and height it is better to state explicitly which direction is considered positive +# when measuring distances. +# +# For the concepts used to specify the boundary_convention it is assumed that the +# region-of-interest is defined by a rectangle, referring to the direction of outer-unit +# normals to the respective edges of this rectangle. +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# center's x-position (PCx) measured. +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the x-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# center's y-position (PCy) measured. +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the y-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# +# This group documents relevant details about the conditions and the +# tools for measuring diffraction patterns with an electron microscope. +# +# The most frequently collected EBSD data are captured for rectangular +# regions-of-interest using a discretization into square or hexagon tiles. +# +# +# +# Physical time since the beginning of a timestamp that is required to be +# the same for all experiments in the set. The purpose of this marker is +# to identify how all experiments in the set need 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, +# 30 minutes, 6 hours, or 24 hours of annealing. +# +# +# +# Timestamp relative to which time was counted to aid +# converting between time and timestamp. +# +# +# +# +# +# Path to an instance of :ref:`NXdata` where the measured patterns are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent data artifact which +# stores either the measured patterns or input (already processed EBSD data). +# +# +# +# +# +# This group documents relevant details about the conditions and the tools +# used for simulating diffraction patterns with some physical model. +# +# This group should be used if (e.g. instead of a measurement) the patterns +# were simulated (possibly awaiting indexing). +# +# In many practical cases where patterns are analyzed on-the-fly and dictionary +# indexing strategies used, so-called master pattern(s) are used to compare +# measured or simulated patterns with the master patterns. +# +# +# +# Path to an instance of :ref:`NXimage` where the simulated patterns are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent digital resource which +# stores either the patterns or input (already processed EBSD data) that are +# about to become processed further as described by this NXem_ebsd instance. +# +# +# +# +# +# The EBSD system, including components like the electron gun, pole-piece, +# stage tilt, EBSD detector, and the gnomonic projection have to be +# calibrated to achieve reliable, precise, and accurate scientific results. +# +# Specifically, the gnomonic projection has to be calibrated. +# Typically, standard specimens made from silicon or quartz crystals +# in specific orientations are used for this purpose. +# +# Considering that a system used is already calibrated well-enough is much +# more frequently the case in practice than that users perform the calibration +# themselves (with above-mentioned standard specimens). +# +# 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 has been calibrated already. Consequently, users pick from +# an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. +# Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). +# +# In the second case, users calibrate the system during the session +# using standards (silicon, quartz, or other common specimens). +# There is usually one person in each lab responsible for doing such +# calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, +# the conventions how orientations are stored is affected by how the +# reference frames are configured and how this setup in the GUI. +# +# 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' obligation to remember these +# settings or write these down in a lab notebook. Otherwise, these metadata +# get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` +# solves in that all conventions can be specified explicitly. +# +# +# +# Path to an instance of :ref:`NXem` where calibration data are stored. +# +# +# +# +# Reference to a digital resource where the calibration is stored. +# +# +# +# +# +# Indexing is a data processing step performed either after or while (aka on-the-fly) +# the beam scans the specimen. The resulting method is also +# known as orientation imaging microscopy (OIM). +# +# Different algorithms can be used to index EBSP. Common to them is the +# computational step where simulated or theoretically assumed patterns +# are compared with the measured ones. These latter patterns are referred +# to via the measurement or simulation groups of this base class respectively. +# +# Quality descriptors are defined based on which an indexing algorithm +# yields a quantitative measure of how similar measured and reference +# patterns are, and thus if no, one, or multiple so-called solutions were found. +# +# Assumed or simulated patterns are simulated using kinematical or dynamical +# theory of electron diffraction delivering master patterns. +# +# The Hough transform, one of the most frequently used traditional method for indexing +# EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods +# find more widespread usage for indexing. +# +# +# +# This group enables to establish a logical connection between previous +# processing steps or on-the-fly-performed indexing of the EBSD map. +# Typically these processing steps are performed with commercial software. +# Therefore, in many cases a results file from this indexing is often +# all that is communicated and saved. These are typically files in a format +# specific to the instrument and its configuration. +# +# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. +# +# +# +# +# Principal algorithm used for indexing. +# +# +# +# +# +# +# +# +# +# Details about the background correction applied to each Kikuchi pattern. +# +# +# +# +# Binning i.e. downsampling to each pattern. +# +# +# +# +# Specific parameter relevant only for certain algorithms used. +# +# +# +# +# Details for each phase used as a model with which the patterns were +# indexed. Instances of :ref:`NXunit_cell` in this group must +# have the group name prefixed with phase. The identifier in the name is an +# integer. Start counting from 1 because the value 0 is reserved for +# the special phase that is the null-model, the null phase also known +# as notIndexed. +# +# +# +# Spacing between the crystallographic planes that are defined via ``miller``. +# +# +# +# +# +# +# +# Relative intensity for the computed diffraction intensity (signal) for the +# plane. +# +# +# +# +# +# +# +# In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps +# this field stores how many scan points of the map were identified as matching best +# with this phase. +# +# +# +# +# How many reflectors for crystallographic planes are distinguished. +# +# +# +# +# Miller indices :math:`(hkl)[uvw]` of the planes. +# +# The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. +# Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. +# +# +# +# +# +# +# +# +# +# Which return value did the indexing algorithm yield for each scan point. +# +# * 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 :ref:`NXunit_cell`. +# +# In another example users may have skipped some scan points (not indexed +# them at all) or used differing numbers of phases for indexing different scan points. +# +# The cumulated of this array decodes how identifier_phase and matching_phase +# 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), +# identifier_phase has as many entries as scan points +# and matching_phase has also as many entries as scan points. +# +# +# +# +# +# +# +# The array phases_per_scan_point details how the identifier_phase +# and the matching_phase arrays have to be interpreted. +# +# For the example with a single phase identifier_phase 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 +# required) that a pattern matches eventually (not equally well) sufficiently +# significant with multiple patterns. This can especially happen in cases of +# pseudosymmetry and more frequently with an improperly calibrated system +# or false or inaccurate phase models. Having such field is especially relevant +# for recent dictionary- or artificial intelligence-based indexing methods to communicate +# the results in a model-agnostic way in combination with matching_phase. +# +# Depending on the phases_per_scan_point value, identifier_phase and +# matching_phase arrays represent a collection of concatenated tuples. +# These 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 phases_per_scan_point. +# +# +# +# +# +# +# +# One-dimensional array, pattern by pattern labelling the solutions found. +# The array phases_per_scan_point has to be specified because it details +# how the identifier_phase and the matching_phase arrays are interpreted. +# See documentation of identifier_phase for further details. +# +# +# +# +# +# +# +# Phase_matching is a descriptor for how well the solution matches or not. +# Examples can be confidence_index, mean_angular_deviation, or other. +# +# +# +# +# +# +# +# +# +# +# Calibrated center positions of each scan point +# in the sample surface reference system. +# +# +# +# +# +# +# +# +# Fraction of successfully indexed patterns with a phase +# not the null-phase vs the number_of_scan_points. +# +# +# +# +# Number of scan points in the original mapping. +# +# +# +# +# +# An overview of the entire ROI. +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# +# +# +# +# Title of the default plot. +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# Descriptor values +# +# +# +# +# +# Calibrated coordinate along the y-axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated coordinate along the x-axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 0b69d411e3..65af168c42 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -133,7 +133,7 @@ NXem_eds(NXprocess): contributes to the intensity of the EDS map. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f4ee4e51409c8bc28b5bb4947e2034139a37f4b7eba4473bf6aa3bd086fd61fa +# cae12797615c334d3bf86e6501d460012fe7e426820d8a9b436f8659e114c3a5 # # # # -# # # # @@ -244,9 +241,6 @@ NXem_eds(NXprocess): # However, a collection of instances of NXpeak with individual NXatom # can be used to add isotopic information and other relevant context. # -# -# -# # # # @@ -280,7 +274,7 @@ NXem_eds(NXprocess): # # # -# +# # # Individual element-specific EDS/EDX/EDXS/SXES mapping # diff --git a/contributed_definitions/nyaml/NXem_measurement.yaml b/contributed_definitions/nyaml/NXem_measurement.yaml index b759d7163d..48c92be810 100644 --- a/contributed_definitions/nyaml/NXem_measurement.yaml +++ b/contributed_definitions/nyaml/NXem_measurement.yaml @@ -6,3 +6,36 @@ NXem_measurement(NXobject): instrument(NXinstrument_em): eventID(NXevent_data_em): nameType: partial + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b316172f1da3439b7e2e8914311c4473c77b211748924007325b78d22ab4bfa2 +# +# +# +# +# +# Base class for documenting a measurement with an electron microscope. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_simulation.yaml b/contributed_definitions/nyaml/NXem_simulation.yaml index 01c289ceaf..bd3bcf6430 100644 --- a/contributed_definitions/nyaml/NXem_simulation.yaml +++ b/contributed_definitions/nyaml/NXem_simulation.yaml @@ -7,3 +7,38 @@ NXem_simulation(NXobject): (NXparameters): (NXprocess): (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c481ee0c18dbbeebd612e013186b8f69866a0cdbc59610bd02a1d819a1af7af0 +# +# +# +# +# +# Base class for documenting a simulation of electron beam-matter interaction. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml index cc1c1295a2..bcf4eff10b 100644 --- a/contributed_definitions/nyaml/NXevent_data_apm.yaml +++ b/contributed_definitions/nyaml/NXevent_data_apm.yaml @@ -135,7 +135,7 @@ NXevent_data_apm(NXobject): instrument(NXinstrument_apm): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 20317c4089aac458ded23af1a3d09887af55ae57a7cc3bf97207fbb434c03eb1 +# 3c8ca2583c2145004aa0cfa43def0e327bd25076c246b0f288380ea0b9fbcc82 # # # +# +# +# +# Base class for a set of components equipping an instrument with FIB capabilities. +# +# Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped +# with sufficient ion having sufficient momentum to remove material in a controlled +# manner. +# +# The fact that an electron microscope with FIB capabilities achieves these functionalities +# via a second component (aka the ion gun) that has its own relevant control circuits, +# focusing lenses, and other components, warrants the definition of 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 flux +# +# +# +# +# Average/nominal brightness +# +# +# +# +# +# Charge current +# +# +# +# +# Ion acceleration voltage upon source exit and +# entering the vacuum flight path. +# +# +# +# +# To be defined more specifically. Community suggestions are welcome. +# +# +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the ion beam. +# +# :ref:`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.yaml b/contributed_definitions/nyaml/NXimage.yaml index 4cc394a540..dd42736dd6 100644 --- a/contributed_definitions/nyaml/NXimage.yaml +++ b/contributed_definitions/nyaml/NXimage.yaml @@ -456,7 +456,7 @@ NXimage(NXobject): Point coordinate along the fastest dimension. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eb25dead780a0229b2caee14dd5458609181ab0c54c30f2fcc888bd8735f9690 +# 60acbd1a10e09aa265edc132f5ba7aa0a721aa2cd5e32f9f5520fd33e9b528db # # # -# # # # Principal design of the stage. @@ -397,14 +396,13 @@ NXinstrument_em(NXinstrument): # # # -# In contrast to the stage, the nanoprobe is an additional manipulator that is specifically +# In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically # frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and -# relocated portions of the specimen that have been cut free to realize specialized -# geometries locally and enable site-specific measurements. +# relocated portions of the specimen that have been cut off during site-specific lift-outs +# and specimen preparation. # -# -# # +# # # # diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml index a116f7c682..7867039cde 100644 --- a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml @@ -27,8 +27,66 @@ doc: | * `S. Richter et al. `_ * `J. Bünger et al. `_ * `J. F. Ziegler et al. `_ - type: group NXinteraction_volume_em(NXobject): (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# aaed5462265171d4bd795348fcd1907519dfa4b05b484b9457cdd10661855ace +# +# +# +# +# +# Base class to describe the volume of interaction for particle-matter interaction. +# +# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam +# interaction simulations can be used to qualify and (or) quantify the shape of +# the interaction volume. Results of such simulations can be summary statistics +# or single-particle-resolved sets of trajectories. +# +# Explicit or implicit descriptions of the geometry of this +# interaction volume 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 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 flux through +# an imaginary control surface (the iso-surface) 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>`_ +# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ +# +# +# +# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index dbaa59122c..28748c9cc6 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -69,7 +69,7 @@ NXion(NXatom): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 618721fcc0b6c6d769b01a05dffea2144953190c4c0f9f5074a20f8eec35f867 +# 6628af1c8c82bda25cfcee865a22cb869cc77412c9459d666475b97f23d911e2 # # # -# +# # # -# 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 atoms/isotopes allowed per (molecular) ion (fragment). +# Maximum number of atoms/isotopes allowed 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. # # # # -# Base class for documenting the set of atoms of a (molecular) ion. +# Base class for documenting the set of atoms of a (molecular) ion. # # # -# A unique identifier whereby such an ion can be referred to -# via the service offered as described in id_type. +# A unique identifier whereby such an ion can be referred to +# via the service offered as described in id_type. # # # # -# How can the identifier be resolved? +# How can the identifier be resolved? # # # @@ -128,20 +128,20 @@ NXion(NXatom): # # # -# 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. # # # # -# Vector of nuclide hash values. -# -# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# encode the number of protons :math:`Z` and the number of neutrons :math:`N` -# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. -# -# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# Vector of nuclide hash values. +# +# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` +# encode the number of protons :math:`Z` and the number of neutrons :math:`N` +# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. +# +# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ # # # @@ -149,78 +149,32 @@ NXion(NXatom): # # # -# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. -# The first column specifies the nuclide mass number, i.e. using the hashvalues -# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no -# isotope-specific information about the element encoded is relevant. -# The second row specifies the number of protons :math:`Z` or 0. -# The value 0 in this case documents a placeholder or that no element-specific -# information is relevant. -# Taking a carbon-14 nuclide as an example the mass number is 14. -# That is encoded as a value pair (14, 6) as one row of the table. -# -# Therefore, this notation is the typical superscribed nuclide mass number -# and subscripted number of protons element notation e.g. :math:`^{14}C`. -# The array is stored matching the order of nuclide_hash. +# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. +# The first column specifies the nuclide mass number, i.e. using the hashvalues +# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no +# isotope-specific information about the element encoded is relevant. +# The second row specifies the number of protons :math:`Z` or 0. +# The value 0 in this case documents a placeholder or that no element-specific +# information is relevant. +# Taking a carbon-14 nuclide as an example the mass number is 14. +# That is encoded as a value pair (14, 6) as one row of the table. +# +# Therefore, this notation is the typical superscribed nuclide mass number +# and subscripted number of protons element notation e.g. :math:`^{14}C`. +# The array is stored matching the order of nuclide_hash. # # # # # # -# -# -# -# Assumed volume of the ion. -# -# In atom probe microscopy this field can be used to store the reconstructed -# volume per ion (average) which is typically stored alongside ranging -# definitions. -# -# -# -# -# Charge of the ion. -# -# -# -# -# Signed charge state of the ion in multiples of electron charge. -# -# In the example of atom probe microscopy, only positive values will be measured -# as the ions are accelerated by a negatively signed bias electric field. -# In the case that the charge state is not explicitly recoverable, the value should -# be set to zero. -# -# In atom probe microscopy this is for example the case when using -# classical ranging definition files in formats like RNG, RRNG. -# These file formats do not document the charge state explicitly -# but the number of atoms of each element per molecular ion -# surplus the mass-to-charge-state-ratio interval. -# Details on ranging definition files can be found in the literature: -# `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# -# -# -# -# Human-readable ion type name (e.g. Al +++) -# The string should consists of UTF-8 characters, ideally using LaTeX -# notation to specify the isotopes, ions, and charge state. -# Examples are 12C + or Al +++. -# -# To ease automated parsing, isotope_vector should be the -# preferred machine-readable information used. -# -# # # -# Associated lower (mqmin) and upper (mqmax) bounds of the -# mass-to-charge-state ratio interval(s) [mqmin, mqmax] -# (boundaries inclusive). This field is primarily of interest -# for documenting :ref:`NXprocess` steps of indexing a -# ToF/mass-to-charge state histogram. +# Associated lower (mqmin) and upper (mqmax) bounds of the +# mass-to-charge-state ratio interval(s) [mqmin, mqmax] +# (boundaries inclusive). This field is primarily of interest +# for documenting :ref:`NXprocess` steps of indexing a +# ToF/mass-to-charge state histogram. # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 8caa715d8d..cbd0dbbcc5 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -676,3 +676,898 @@ NXmicrostructure(NXobject): Non-intrinsic mobility of each quadruple_junction. dimensions: dim: (n_qj,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f8600220a6aaf2b6d382041736e46e1e6ae8825b7f546bece82f34ed3b095efb +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of crystals or their projections +# +# +# +# +# The number of interfaces or their projections +# +# +# +# +# The number of triple junctions or their projections +# +# +# +# +# The number of quadruple junctions or their projections +# +# +# +# +# +# The number of one-dimensional crystal projections +# +# +# +# +# The number of one-dimensional interface projections +# +# +# +# +# +# The number of two-dimensional crystal projections +# +# +# +# +# The number of two-dimensional interface projections +# +# +# +# +# The number of two-dimensional triple line projections +# +# +# +# +# The number of two-dimensional line defect projections +# +# +# +# +# +# The number of crystals (grain and sub-grain are exact synonyms for crystal). +# +# +# +# +# The number of interfaces (grain boundary and phase boundary are subclasses of +# interfaces). +# +# +# +# +# The number of triple junctions (triple line is a exact synonym for triple +# junction, triple point is projection of a triple junction). +# +# +# +# +# The number of quadruple junctions. +# +# +# +# +# +# The dimensionality of the representation that needs to match the value for +# configuration/dimensionality +# +# +# +# +# Base class to describe a microstructure, its structural aspects, associated descriptors, properties. +# +# Whether one uses a continuum or atomic scale description of materials, these are always a model only of +# the true internal structure of a material. Such models are useful as they enable a coarse-graining and +# categorizing of properties and representational aspects from which measured or simulated descriptions +# can be correlated with properties, i.e. descriptor values. The base class here can be used to describe +# the structural aspect of a region-of-interest for a specimen that was investigated or a computer +# simulation that was performed for a virtual specimen. +# +# Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, +# the characterized microstructure may not turn out to be the same structure as of the untreated +# sample from which the region-of-interests on the specimen were sampled. +# +# Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' +# structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually +# always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation +# (projection) of the characterized material volume. Often materials are characterized only for specific states +# or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. +# This is typically a compromise between the research questions and technical surplus practical limitations. +# +# The term microstructural feature covers here crystals and all sorts of crystal defects within the material +# (interfaces, triple junctions, dislocations, pores, etc.). +# A key challenge with the description of representations and properties of such microstructural features is that +# they can be represented and view as features with different dimensionality. Furthermore, combinations of features of +# different dimensionality are frequently expected to be documented with intuitive naming conventions when +# flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based +# on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. +# +# NXmicrostructure is an attempt to standardize these descriptions stronger. +# +# For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and +# junctions of different types of crystal defects. The term grain describes a contiguous region of material that is +# delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though +# a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. +# In this base class we use the term and respective group crystals though for single crystals and grains. +# The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume +# that the internal structure of these grains can be described with homogenized effective properties. +# If alternatively the individual structural crystalline or features of this grain should be distinguished +# it is useful to instantiate these as individual instances of crystals. +# +# Grain boundaries and phase boundaries are two main categories of interfaces. +# A grain boundary delineates two regions with similar crystal structure and phase but different orientation. +# A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically +# but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two +# phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments +# but considers that atomic segregation is an equally important structural aspect to consider when classifying grain +# boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties +# is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and A. Sutton and R. W. Baluffi, +# Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. +# +# Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in +# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. +# Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, +# or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material +# properties or affect material properties. +# +# Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values +# which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms +# are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional +# description such as a triple line or a triple point as the projection of a line. Therefore, different representations can +# be used to describe the location, shape, and structure of such defect. +# +# This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, +# volumetric, patch, line, and point like features that can serve as examples for future extension. +# +# As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable +# objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations +# as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- +# triple-line junctions, likewise dislocations form own junctions. +# +# The description took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ +# and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. +# +# Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined +# on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers +# for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. +# +# +# +# +# Discouraged free-text field for leaving comments +# +# +# +# +# ISO8601 with offset to local time zone included when a timestamp is required. +# +# +# +# +# Measured or simulated physical time stamp for this microstructure snapshot. +# Not to be confused with wall-clock timing or profiling data. +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# Group where to store details about the configuration and parameterization of algorithms +# used whereby microstructural features were identified. +# +# +# +# Dimensionality of Euclidean space in which the analysis is performed. +# +# This field can be used e.g. by a research data management system to identify +# if the description specifies one-, two-, or three-dimensional microstructural representations. +# +# +# +# +# +# +# +# +# +# Algorithm whereby interfaces between crystals were reconstructed. +# +# * Disorientation clustering groups nearby material points based on their crystallographic disorientation +# * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ +# * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ +# +# +# +# +# +# +# +# +# +# +# +# Threshold to define at which disorientation angle to assume two crystalline regions have a significant +# orientation difference that warrants to assume that there exists an interface between the two regions. +# +# +# +# +# The program with which the microstructure was reconstructed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The chemical composition of this microstructure (region). +# +# +# +# +# +# +# +# +# +# +# Different (thermodynamic) phases can be distinguished for the region-of- +# interest. +# +# +# +# First identifier whereby to identify phases implicitly. +# +# +# +# +# +# +# One- or two-dimensional projections, or three-dimensional representations of crystals. +# +# An example for a volume bounded by other crystal defects. Crystals can be grains of +# different phases, precipitates, dispersoids; there are many terms used specifically in +# the materials engineering community. +# +# Typically, crystals are measured on the surface of a sample via optical or electron microscopy. +# Using X-ray diffraction methods crystals can be observed in bulk specimens. +# +# Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. +# In rare cases the volume bounded gets represented using constructive solid geometry approaches. +# +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) +# * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# How many crystals are distinguished. +# +# Crystals are listed irrespective of the phase to which these are assigned. +# +# +# +# +# How many phases are distinguished. +# +# Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. +# +# +# +# +# First identifier whereby to identify crystals implicitly. +# +# +# +# +# Identifier whereby to identify each crystal explicitly. +# +# +# +# +# +# +# +# Identifier whereby to identify phase for each crystal explicitly. +# +# +# +# +# +# +# +# +# True, if the feature makes contact with the edge of the ROI. +# False, if the feature does not make contact with the edge of the ROI. +# +# +# +# +# +# +# +# Average disorientation angle for each crystal between individual orientations +# of that crystal evaluated as a summary statistic for all probed positions vs the +# average disorientation of that crystal. +# +# +# +# +# +# +# +# Length of each crystal +# +# +# +# +# +# +# +# Area of each crystal. +# +# +# +# +# +# +# +# Volume of each crystal +# +# +# +# +# +# +# +# Possibility to store the mean orientation of the grain. +# +# +# +# +# +# One- or two-dimensional projections or three-dimensional representation of interfaces +# between crystals as topological entities equivalent to dual_junctions. +# +# An example for a surface defect. Most important are interfaces such as grain and phase boundaries +# but factually interfaces also exist between the environment and crystals exposed at the +# surface of the specimen or internal surfaces like between crystals, cracks, or pores. +# +# Interfaces are typically reported as discretized features. For interface projections on the 2D plane +# these are most frequently polyline segments. For interface patches in 3D these are most frequently +# triangulations. Descriptions with continuous functions are seldom used unless simplified configurations +# are studied in modeling and theoretical studies. +# +# When using discretizations the individual interface segments need to be distinguished from the interfaces +# themselves. Consequently, there are two sets of indices. +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) +# * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks +# (like in computer simulations or 3D experiments) +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# How many interfaces are distinguished. +# +# +# +# +# First identifier whereby to identify interfaces implicitly. +# +# +# +# +# Identifier whereby to identify each interface explicitly. +# +# An array with as many entries as interfaces or their projections. +# +# +# +# +# +# +# +# +# Set of pairs of indices_crystal values, for each interface one value pair. +# +# An array with as many pairs as interfaces or their projections. +# +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# Set of pairs of indices_phase values, for each interface one value pair. +# +# An array with as many pairs as interfaces or their projections. +# +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional +# projections. The latter situation applies typically for characterization with electron +# microscopy. +# +# In the case of a two-dimensional projection interfaces are interface traces. These have +# two terminating junctions. In three dimensions though the interface is a surface patch +# that is bounded by multiple triple lines. +# +# Number of triple_junctions adjoining each interface. This array resolves the number of +# values along the second dimension for the field indices_triple_junctions. +# +# +# +# +# +# +# +# Set of pairs of indices_triple_junction for each interface. +# +# An array with as many tuples of pairs to describe +# all junctions about all interfaces. +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# True, if the interface makes contact with the edge of the ROI. +# False, if the interface does not make contact with the edge of the ROI. +# +# +# +# +# +# +# +# Gibbs free surface energy for each interface. +# +# +# +# +# +# +# +# Non-intrinsic mobility of each interface. +# +# +# +# +# +# +# +# The length of each interface if only projections are available. +# +# This is not necessarily the same as the length of the individual +# polyline segments whereby the interface is discretized. +# +# +# +# +# +# +# +# The surface area of all interfaces. +# +# +# +# +# +# +# +# +# Projections or representations of junctions at which three interfaces meet. +# +# An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, +# or junctions observed between crystals (at the specimen surface exposed to an environment) +# (including wetting phenomena) or inside the specimen (crack, pores). +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_polyline` for a two-dimensional representation as only a projection is available +# * :ref:`NXcg_polygon` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution +# and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles +# * :ref:`NXcg_polyhedron` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms +# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# Number of triple junctions. +# +# +# +# +# First identifier to identify triple junctions implicitly. +# +# +# +# +# Identifier to identify each triple junction explicitly. +# +# +# +# +# +# +# +# +# Set of identifier for positions whereby to identify the location of each +# junction. +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# Explicit positions. +# +# +# +# +# +# +# +# +# Set of tuples of identifier of crystals connected to the junction for each +# triple junction. +# +# +# +# +# +# +# +# +# +# Set of tuples of identifier of interfaces connected to the junction for each +# triple junction. +# +# +# +# +# +# +# +# The specific interface identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for polyline segments connected to the junction for +# each triple junction. +# +# +# +# +# +# +# +# The specific indices_polyline whereby to resolve ambiguities. +# +# +# +# +# +# +# True, if the triple line makes contact with the edge of the ROI. +# False, if the triple line does not make contact with the edge of the ROI. +# +# +# +# +# +# +# +# Specific line energy of each triple junction +# +# +# +# +# +# +# +# Non-intrinsic mobility of each triple junction. +# +# +# +# +# +# +# +# The length of each triple junction. +# +# This is not necessarily the same as the length of the individual +# polyline segments whereby the junction is discretized. +# +# +# +# +# +# +# +# The volume about each triple junction. +# +# Respective cut-off criteria need to be specified. +# +# +# +# +# +# +# +# +# Quadruple junctions as a region where four crystals meet. +# +# An example for a point (like) defect. +# +# Thermodynamically such junctions can be unstable. +# Specifically when discretizations are used in simulations +# that do not address the thermodynamics of and splitting characteristics +# of junctions in cases when more than four crystals meet, it is possible +# that so-called higher-order junctions are observed. +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point` +# * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# Number of quadruple junctions. +# +# +# +# +# First identifier to identify quadruple junctions implicitly. +# +# +# +# +# Identifier to identify each quadruple junction explicitly. +# +# +# +# +# +# +# +# +# Set of identifier for positions whereby to identify the location of each +# junction. +# +# +# +# +# +# +# The specific point identifier whereby to resolve ambiguities. +# +# +# +# +# +# Explicit positions. +# +# +# +# +# +# +# +# +# +# Set of tuples of identifier of crystals connected to the junction for each +# junction. +# +# +# +# +# +# +# +# The specific identifier to instances of crystal identifiers whereby to resolve +# ambiguities. +# +# +# +# +# +# Set of tuples of identifier of interfaces connected to the junction for each +# junction. +# +# +# +# +# +# +# +# The specific identifier to instances of interface identifiers whereby to resolve +# ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for triple junctions connected to the junction for +# each quadruple junction. +# +# +# +# +# +# +# +# The specific identifier to instances of triple junction identifiers whereby to +# resolve ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for phases of crystals connected to the junction for +# each quadruple junction. +# +# +# +# +# +# +# +# The specific identifier to instances of phase identifier whereby to resolve +# ambiguities. +# +# +# +# +# +# +# True, if the junction makes contact with the edge of the ROI. +# True, if the junction does not make contact with the edge of the ROI. +# +# +# +# +# +# +# +# Energy of the quadruple_junction as a defect. +# +# +# +# +# +# +# +# Non-intrinsic mobility of each quadruple_junction. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_feature.yaml b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml index 68b3a52304..e080083e5d 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_feature.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml @@ -3,3 +3,34 @@ doc: | Base class for documenting structuring features of a microstructure. type: group NXmicrostructure_feature(NXobject): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8afbe5a4c005a47e243ff942505d8700eb461a99cfa0b9b663e52a85ee0b4155 +# +# +# +# +# +# Base class for documenting structuring features of a microstructure. +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index 903a0e3550..0c0cb4422d 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -282,3 +282,375 @@ NXmicrostructure_gragles_config(NXobject): # 1 # 1 25 # + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4019d30d296ef8868c338bcbdbfd01d5c68a2e3e11d2bc66294c36161c18606c +# +# +# +# +# +# +# Application definition for configuring GraGLeS. +# +# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations +# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. +# CPU parallelization is achieved with OpenMP. +# +# The code has been implemented by C. Mießen in the group of G. Gottstein +# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. +# +# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# From which file should the microstructure be instantiated. +# +# +# +# +# +# +# +# +# The formulation of mean curvature flow in the GraGLeS model is scale invariant. +# Therefore, the discretization has to be scaled to the actual physical length +# of the simulation domain (ve, ROI). +# For GraGLeS the discretization is always a square or cubic axis-aligned +# bounding box with a regular tiling into material points +# (either squares or cubes respectively). +# +# Edge_length is the length of the entire domain along its edge not +# the length of the Wigner-Seitz cell about each material point! +# +# +# +# +# +# Configuration when snapshots of the system should be taken. +# +# Keep in mind that essentially geometry snapshot data store the +# polylines and polyhedra of all grains which can take substantial disk +# space. +# +# +# +# Generate a snapshot of the properties of the grains to follow +# the evolution of the microstructure every :math:`n`-th iteration. +# Setting zero causes that no property snapshots are taken. +# +# +# +# +# Generate a snapshot of the geometry of the entire grain boundary network +# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. +# +# +# +# +# +# +# Configuration when the simulation should be stopped in a controlled manner. +# Whichever criterion is fulfilled first triggers the controlled stop of +# and termination of GraGLeS. +# +# +# +# The simulation stops if the total number of grains +# becomes smaller than this criterion. +# +# +# +# +# The simulation stops if more iterations than this criterion have been computed. +# +# +# +# +# +# Configuration of numerical details of the solver. +# +# +# +# +# Which type of convolution kernel and model is used. +# +# +# +# +# +# +# +# +# +# Constant to calibrate the real time scaling of the simulation. +# +# +# +# +# +# +# Configuration of the grid coarsement algorithm whereby the representation +# of the system is continuously rediscretized such that on average grains +# are discretized with discretization many material points along each +# direction. +# +# Grid coarsement can reduce the computational costs substantially although +# it cannot be ruled out completely that the rediscretizing may have an effect +# on the system evolution. Without grid coarsement the total number of material +# points to consider stays the same throughout the simulation. +# +# +# +# Number of material points along each direction to discretize the +# average grain. The larger this value is chosen the finer the curvature +# details are that can be resolved but also the longer the simulation +# takes. +# +# +# +# +# If true grid coarsement is active, otherwise it is not. +# +# +# +# +# Fraction how strongly the number of grains has to reduce +# to trigger a grid coarsement step in an iteration. +# +# +# +# +# +# +# Physically-based model of the assumed mobility of the grain boundaries. +# +# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent +# especially as grain boundaries in reality are decorated with defects as a consequence of which +# the actual mobility is a combination of the mobility of the individual defects and the attached +# boundary patches. Grain boundaries have different degrees of microscopic freedom. +# Therefore, their mobility follows a distribution. +# +# +# +# +# Fundamental model how :math:`m` is assumed a function of the disorientation +# angle :math:`\Theta`. +# +# +# +# +# +# +# +# +# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed +# temperature. GraGLeS was developed for modelling isothermal annealing. +# +# +# +# +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. +# +# +# +# +# +# Mobility scaling factor :math:`c_2`. Typically 5. +# +# +# +# +# Mobility scaling factor :math:`c_3`. Typically 9. +# +# +# +# +# +# Physically-based model of the assumed grain boundary surface energy. +# +# Like for the grain boundary mobility, defects cause a distribution of energies for the +# patches of which the boundary is composed. In practice a too complicated dependency +# of the energy and mobility model is observed as a function of the type and chemical +# decoration of the defects. Therefore, simplifying assumptions are typically made. +# +# +# +# Fundamental type of assumption if energies are considered isotropic or not. +# +# +# +# +# +# +# +# +# Fundamental model how :math:`\gamma` is assumed a function of the disorientation +# angle :math:`\Theta`. +# +# +# +# +# +# +# +# Mean grain boundary surface energy that is assumed a function of the +# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. +# This value factorizes the curvature_driving_force model. +# +# +# +# +# +# +# A continuum-scale curvature of an interface causes the interface to +# migrate towards the center of the curvature radius. +# +# +# +# If true the curvature_driving_force is considered, otherwise it is not. +# +# +# +# +# +# A continuum-scale difference of the stored elastic energy in dislocation +# configurations across a grain boundary can exert a driving force on the +# grain boundary such that the boundary migrates into the volume with the +# higher stored elastic energy. +# +# +# +# If true the dislocation_driving_force is considered, otherwise it is not. +# +# +# +# +# Prefactor :math:`0.5Gb^2` that factorizes the average +# stored elastic energy per length dislocation line. +# +# +# +# +# +# In case of an applied magnetic field, a difference of the magnetic +# susceptibility can exert a driving force on the grain boundary such that +# the boundary migrates into the volume with the higher magnetic energy. +# +# +# +# If true the magnetic_driving_force is considered, otherwise it is not. +# +# +# +# +# +# +# A triple line mediates the atomic arrangement differences between three +# interface patches. Therefore, the triple line is a defect that may not +# have the same mobility as adjoining grain boundaries and thus it may +# exert what can be conceptualized as a drag (resistance) to the motion +# of the adjoining interface patches. +# +# +# +# Assumed triple junction drag. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index b85096d6b0..51dcbfdd1e 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -212,3 +212,299 @@ NXmicrostructure_gragles_results(NXobject): dimensions: rank: 1 dim: (n_interfaces,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ce46d9c44dd5374e61f88bb2cb3a620e5b2c51e149e8d021a5969dbf58bc4b42 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of summary statistic log entries. +# +# +# +# +# Number of grains in the computer simulation. +# +# +# +# +# Number of interfaces in the computer simulation. +# +# +# +# +# Application definition for documenting results with GraGLeS. +# +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Documentation of the spatiotemporal evolution +# +# +# +# +# Summary quantities which are the result of some post-processing of the snapshot data +# (averaging, integrating, interpolating) happening in for practical reasons though in while +# running the simulation. Place used for storing descriptors from continuum mechanics +# and thermodynamics at the scale of the entire ROI. +# +# +# +# Evolution of the recrystallized volume fraction over time. +# +# +# +# Evolution of the physical time not to be confused with wall-clock time or +# profiling data. +# +# +# +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# How many crystals are distinguished. +# Crystals are listed irrespective of the phase to which these are assigned. +# +# +# +# +# +# +# +# +# +# Which type of stress. +# +# +# +# +# +# +# +# Applied external stress tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of strain. +# +# +# +# +# Applied external strain tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of deformation gradient. +# +# +# +# +# +# +# +# Applied deformation gradient tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Applied external magnetic field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external electrical field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Simulated temperature for this snapshot. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# One pair of indices_crystal values for each interface. +# +# +# +# +# +# +# +# +# +# Mobility times surface energy density of the interface normalized +# to the maximum such product of the interface set. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index 88fd1b3d2e..9673fb8c94 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -174,3 +174,248 @@ NXmicrostructure_imm_config(NXobject): # 0.00 # 1.00 # +# +# +# +# +# +# +# How many texture components are distinguished, minimum is 1. +# +# +# +# +# How many special texture components are distinguished if any. +# +# +# +# +# Number of discrete orientations that are distributed across the grains. +# +# +# +# +# Application definition for the configuration of the legacy (micro)structure generator +# developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. +# +# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ +# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ +# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ +# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ +# +# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. +# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. +# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. +# +# +# +# +# +# +# +# +# +# The computational domain will be synthesized either as a square (for dimensionality = 2) +# or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is +# discretized into material points using either square pixel or cubic voxel as the tessellating +# unit cells. +# +# +# +# Two-dimensional or three-dimensional simulation. +# +# +# +# +# +# +# +# +# Target value for the number of material points per equivalent +# discrete diameter of the arithmetic average sub-grain. +# +# +# +# +# Assumed space group of the material. +# +# +# +# +# +# +# +# +# +# +# Target value for the number of grains. The actual domain size and grid will be configured +# based on the choices for discretization, number_of_grains, and shape of these grains. +# +# +# +# +# Target value for the average number of sub-grains per grain. +# +# +# +# +# +# If available used to define the sequence of relative extent of grains along the y (first value) +# and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, +# the relative extent of the grains will be 1 one average along each axis (globulitic structure). +# +# +# +# +# +# +# +# +# +# In texture research component analyses set on the idea that properties +# of grains different based on orientation with certain regions in orientation +# space show similar trends like a different average dislocation density +# or orientation_spread. +# +# +# +# The first entry is always the null model None which means that an orientation +# is not categorized as a special component. Examples for special components are +# Dillamore, Copper, Cube, Y, P and Q. +# +# +# +# +# +# +# +# Bunge-Euler angle parameterization of the texture components +# location in orientation space for which specifically different settings +# should be configured. +# +# +# +# +# +# +# +# +# Disorientation angle below which an orientation is categorized as one of the +# components. +# +# +# +# +# +# +# +# +# Dislocations are modelled as Rayleigh-distributed mean-field density that +# can differ between but is constant within grains and sub-grains. +# +# +# +# The minimum and the maximum dislocation density to distribute across grains. +# +# +# +# +# +# +# +# +# The minimum and the maximum dislocation density to distribute across sub-grains. +# +# +# +# +# +# +# +# +# +# +# The variance of the dislocation density distribution across the grains. +# +# +# +# +# +# +# +# The variance of the dislocation density distribution across the sub-grains. +# +# +# +# +# +# +# +# +# Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. +# Orientations of the sub-grains are sampled by scattering the orientation +# of the (parent) grain and with optional Rayleigh-distributed scatter. +# +# +# +# Bunge-Euler angle parameterization of the texture components +# location in orientation space for which specifically different settings +# should be configured. +# +# +# +# +# +# +# +# +# The variance of the disorientation of the sub-grain to their parent grain. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index fbe32506ac..a95ae3524b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -135,3 +135,195 @@ NXmicrostructure_imm_results(NXobject): dimensions: rank: 1 dim: (c,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f8a8ae246a82288cbe1dffe13e542acca67b88bdf48c0c56c9f2b33c300af7ad +# +# +# +# +# +# +# +# Number of material points along the edge of the square- or cube-shaped domain. +# +# +# +# +# Number of crystals. +# +# +# +# +# Application definition for the results of the legacy (micro)structure generator developed +# by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. +# +# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ +# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ +# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ +# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ +# +# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. +# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. +# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. +# +# +# +# +# +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# Default plot showing the grid. +# +# +# +# +# +# +# +# Crystal identifier that was assigned to each material point. +# +# +# +# +# +# Material point barycenter coordinate along z direction. +# +# +# +# +# +# +# Coordinate along z direction. +# +# +# +# +# +# Material point barycenter coordinate along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Material point barycenter coordinate along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# True if the crystal is considered a sub-grain. +# False if the crystal is considered a grain. +# +# +# +# +# +# +# +# Bunge-Euler angle orientation of each crystal. +# +# +# +# +# +# +# +# +# Mean-field dislocation density as a measure of the stored elastic energy +# content that is stored in the dislocation network of this grain and related +# defects within each crystal. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 13e391e4fb..a8d045d21e 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -137,3 +137,199 @@ NXmicrostructure_kanapy_results(NXobject): dimensions: rank: 2 dim: (c, 3) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5ae64c7665dc9fef2170ef9bc002aa61b056d3737550c7df60465e2b82812e90 +# +# +# +# +# +# +# +# Number of material points along the z axis of the domain. +# +# +# +# +# Number of material points along the y axis of the domain. +# +# +# +# +# Number of material points along the x axis of the domain. +# +# +# +# +# Number of crystals. +# +# +# +# +# Application definition for the microstructure generator kanapy from ICAMS Bochum. +# +# * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ +# +# A draft application definition to support discussion within the infrastructure use case IUC07 of the +# NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations +# of spatiotemporal microstructure evolution with scientific software from this community. +# +# +# +# +# +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Default plot showing the grid. +# +# +# +# +# +# +# +# Crystal identifier that was assigned to each material point. +# +# +# +# +# +# Material point barycenter coordinate along z direction. +# +# +# +# +# +# +# Coordinate along z direction. +# +# +# +# +# +# Material point barycenter coordinate along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Material point barycenter coordinate along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Bunge-Euler angle orientation of each crystal. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index 79187f804b..13f602353d 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -203,7 +203,7 @@ NXmicrostructure_mtex_config(NXobject): # version as an instance of (NXprogram) one for MTex one for Matlab # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2be867a24501f8d04bb94d529ceb202b9c1e69f62738afaeeceec3097f986c54 +# 32c667a8f682fa2834350deffda1f237886ccc28172411f4b971cdf8bbfbec50 # # # +# doc: | +# TODO with MTex developers +# unit: NX_UNITLESS--> # # # @@ -415,7 +415,11 @@ NXmicrostructure_mtex_config(NXobject): # TODO with MTex developers # # -# +# +# +# TODO with MTex developers +# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index cf8062e313..a719457a9b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -153,3 +153,230 @@ NXmicrostructure_odf(NXprocess): dim: (n_varphi_two,) # \@long_name(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5d52f1f8a723d36d233224b8f5a256dda4d1882c51e444019259a58e094e532b +# +# +# +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest +# direction. +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\Phi` fast direction. +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\varphi_2` slow +# direction. +# +# +# +# +# Number of local maxima evaluated in the component analysis. +# +# +# +# +# Number of sampled positions in orientation space. +# +# +# +# +# Base class to store an orientation distribution function (ODF). +# +# An orientation distribution function is a probability distribution that details how +# much volume of material has a specific orientation. An ODF is computed from +# pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. +# +# +# +# Details about the algorithm used for computing the ODF. +# +# +# +# Point group of the crystal structure of the phase for which the here documented phase- +# dependent ODF was computed.(following the notation of the International Table of Crystallography). +# +# +# +# +# Point group assumed for additionally considered sample symmetries +# following the notation of the International Table of Crystallography). +# +# +# +# +# Halfwidth of the kernel. +# +# +# +# +# Name of the kernel. +# +# +# +# +# Resolution of the kernel. +# +# +# +# +# +# +# Group to store descriptors and summary statistics for extrema of the ODF. +# +# +# +# Minima or maxima, if extrema is set to minima values for location and volume_fraction +# are sorted in increasing order. If extrema is set to maxima values for location and +# volume_fraction are sorted in decreasing order. Therefore, the global extremum is +# always the first entry in location and volume_fraction. +# +# +# +# +# +# +# +# +# Number of local extrema evaluated +# +# +# +# +# +# Disorientation threshold within which intensity of the ODF +# is integrated for the component analysis. +# +# +# +# +# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most +# maxima in decreasing order of the intensity maximum. +# +# +# +# +# +# +# +# +# Integrated ODF intensity within a theta angular region of the orientation space (SO3) +# about each location (obeying symmetries) as specified for each location. +# +# +# +# +# +# +# +# +# The ODF intensity values (weights) as sampled with a software. +# +# +# +# Sampling resolution +# +# +# +# +# Bunge-Euler (i.e. ZXZ convention) locations of each position +# in orientation space for which a weight was sampled. +# +# +# +# +# +# +# +# +# Weight at each sampled position following the order in euler. +# +# +# +# +# +# +# +# +# Visualization of the ODF intensity as discretized orthogonal sections through +# orientation space parameterized using Bunge-Euler angles. +# +# This is one example of typical default plots used in the texture community in materials engineering. +# +# Mind that the orientation space is a distorted space when it using an Euler angle parameterization. +# Therefore, equivalent orientations show intensity contributions in eventually multiple locations. +# +# +# +# +# ODF intensity at probed locations relative to the intensity of the null model of +# a random texture. +# +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\varphi_1` direction. +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\Phi` direction. +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\varphi_2` direction. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 914ad9bd88..2f3baf2ffd 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -70,3 +70,120 @@ NXmicrostructure_pf(NXprocess): dim: (n_x,) # \@long_name(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e223447279e34d5e625e75d19036369c8a20ecca8fa14ae7d446aa91917249f5 +# +# +# +# +# +# +# +# Number of pixel per pole figure in the slow direction. +# +# +# +# +# Number of pixel per pole figure in the fast direction. +# +# +# +# +# Base class to store a pole figure (PF) computation. +# +# A pole figure is the X-ray diffraction intensity for specific integrated +# peaks for a hemispherical illumination of a real or virtual specimen. +# +# +# +# Details about the algorithm that was used to compute the pole figure. +# +# +# +# Point group of the crystal structure of the phase for which the pole figure +# was computed (according to International Table of Crystallography). +# +# +# +# +# Point group of assumed sample symmetries (according to International Table of +# Crystallography). +# +# +# +# +# +# Halfwidth of the kernel. +# +# +# +# +# Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. +# +# +# +# +# Resolution of the kernel. +# +# +# +# +# +# Pole figure. +# +# +# +# +# Pole figure intensity. +# +# +# +# +# +# +# +# +# Pixel center along y direction in the equatorial plane of +# a stereographic projection of the unit sphere. +# +# +# +# +# +# +# +# +# Pixel center along x direction in the equatorial plane of +# a stereographic projection of the unit sphere. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index eab96f97b4..716022c398 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -534,3 +534,733 @@ NXmicrostructure_score_config(NXobject): 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 68eef00573d978ee8505c363acca7f7c1ec47ce1c5c7fc2022fe7b87ae50ddb3 +# +# +# +# +# +# +# +# Number of Bunge-Euler angle triplets for deformed grains. +# +# +# +# +# Number of Bunge-Euler angle triplets for recrystallization nuclei. +# +# +# +# +# Number of texture components to analyze. +# +# +# +# +# Number of support points for the linearized drag profile. +# +# +# +# +# Number of support points for the desired time-temperature profile. +# +# +# +# +# Number of entries when to defragment i.e. garbage collect the memory holding +# state information for recrystallized cells. +# +# +# +# +# Number of entries when to collect snapshots of the evolving microstructure. +# +# +# +# +# Number of solitary unit domains to export. +# +# +# +# +# Dimensionality of the simulation. +# +# +# +# +# Application definition to configure a simulation with the SCORE model. +# +# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ +# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ +# +# +# +# +# +# +# +# +# +# An alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the configuration file was created. +# +# +# +# +# +# +# +# +# Dimensionality of the simulation. +# +# +# +# +# +# +# +# A qualifier whether the sample is a real one or a virtual one. +# +# +# +# +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from other sources. +# +# +# +# +# +# Name of the program whereby this config file was created. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# (Mechanical) properties of the material which scale the +# amount of stored (elastic) energy in the system and +# thus mainly affect recrystallization kinetics. +# +# +# +# Reference shear modulus at zero Kelvin. +# +# +# +# +# Magnitude of the Burgers vector at zero Kelvin. +# +# +# +# +# +# Melting temperature +# +# +# +# +# +# Details about the geometry and properties of the polycrystal that represents the +# starting configuration (typically a deformed microstructure) for the simulation. +# +# +# +# Which model should be used to generate a starting microstructure. +# +# * cuboidal, a regular array of equally shaped cuboidal grains +# * poisson_voronoi, a discretized poisson voronoi +# * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map +# * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. +# +# +# +# +# +# +# +# +# +# +# +# Extent of each deformed grain in voxel along the +# x, y, and z direction when model is cuboidal. +# +# +# +# +# +# +# +# Average spherical diameter when model is poisson_voronoi. +# +# +# +# +# Settings for instantiating properties of deformed grains when model is cuboidal +# or poisson. +# +# +# +# Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) +# out of which the orientations of deformed grains are sampled. +# +# +# +# +# +# +# +# +# Set of stored elastic energy quantified as a dislocation density which is assigned +# to deformed grains with orientations from bunge_euler with index queries matching +# for the bunge_euler and stored_energy fields. +# +# +# +# +# +# +# +# +# Settings for instantiating properties of deformed grains from an +# EBSD orientation map when model is cuboidal or poisson. +# +# +# +# +# +# +# +# +# +# +# Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels +# or cube-shaped voxels respectively. +# +# +# +# +# +# +# +# +# Settings for instantiating properties of deformed grains and nuclei when model +# is damask. +# +# +# +# Name of the DREAM.3D HDF5 file that was instantiated from the +# a previously performed DAMASK simulation. +# +# +# +# +# +# +# +# +# +# +# +# +# Phenomenological model according to which recrystallization nuclei +# are placed into the domain whose growth is studied with the simulation. +# +# +# +# According to which model will the nuclei become distributed spatially: +# +# * csr, complete spatial randomness +# * custom, implementation-specific +# * gb, nuclei placed at grain boundaries +# +# +# +# +# +# +# +# +# According to which model will the nuclei start to grow. +# +# +# +# +# +# +# +# According to which model will the nuclei get their orientation assigned: +# +# * ensemble, picking randomly one from ensemble/bunge_euler +# * random, picking randomly on the SO3 +# * damask, picking based on information provided in deformation/damask +# +# +# +# +# +# +# +# +# +# +# Settings for instantiating properties of nuclei for recrystallizing grains. +# +# +# +# Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) +# out of which the orientations of nuclei/recrystallized grains are sampled. +# +# +# +# +# +# +# +# +# Incubation time which is assigned to deformed grains with orientations from bunge_euler +# with index queries matching for the bunge_euler and stored_energy fields. +# +# +# +# +# +# +# +# +# +# Model for the assumed mobility of grain boundaries with different disorientation +# implemented as parameterized Turnbull's model for thermally-activated +# grain boundary migration. +# +# +# +# Which type of fundamental model for the grain boundary mobility. +# +# Grain boundaries with disorientation angle smaller than 15 degree are considered +# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. +# +# +# +# +# +# +# +# +# +# Parameter of the Sebald-Gottstein migration model. +# +# +# +# +# Pre-exponential factor for low-angle grain boundaries. +# +# +# +# +# Migration activation enthalpy for low-angle grain boundaries. +# +# +# +# +# Pre-exponential factor for high-angle grain boundaries. +# +# +# +# +# Migration activation enthalpy for high-angle grain boundaries. +# +# +# +# +# Pre-exponential factor for high-angle grain boundaries which in +# bicrystal or other tailored experiments showed a particular high +# mobility. +# +# +# +# +# Migration activation enthalpy for high-angle grain boundaries which in +# bicrystal or other tailored experiments showed a particular high +# mobility. +# +# +# +# +# +# Parameter of the Rollett-Holm migration model. +# +# +# +# +# Pre-exponential factor for the fastest grain boundary in the system. +# +# +# +# +# Migration activation enthalpy for the fastest grain boundary in the system. +# +# +# +# +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not 1. +# +# +# +# +# Mobility scaling factor :math:`c_2`. Typically 5. +# +# +# +# +# Mobility scaling factor :math:`c_3`. Typically 9. +# +# +# +# +# +# +# Time-dependent reduction of the stored energy to account for recovery effects. +# +# +# +# Which type of recovery model. +# +# +# +# +# +# +# +# +# Reduction of the grain boundary migration speed due to the presence of dispersoids +# through which the total grain boundary area of the recrystallization front can be reduced +# while the boundary is arrested at the dispersoids. +# +# +# +# Which type of drag model. +# +# +# +# +# +# +# +# +# +# Parameter of the Zener-Smith drag model when model is zener_smith. +# +# +# +# Configuration-dependent constant which factorizes the drag pressure. +# +# +# +# +# Average surface energy of the grain-boundary-dispersoid-surface configuration +# which factorizes the drag pressure. +# +# +# +# +# +# Assumed dispersoid mean radius-time profile +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# Given name of a texture component. +# +# +# +# +# +# +# +# Bunge-Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the +# of texture components in sequence of the name field. +# +# +# +# +# +# +# +# +# Integration radius that constraints the theta angular region of the orientation space (SO3) +# about each central location (obeying symmetries) as specified by bunge_euler indexed in +# the same sequence as the bunge_euler and name fields. +# +# +# +# +# +# +# +# +# Desired 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. +# +# +# +# +# +# +# +# +# +# Relevant data to instantiate a starting configuration that is typically +# a microstructure in deformed conditions where (elastic) energy is stored +# in the form of crystal defects (mostly dislocations). The SCORE model +# does not resolve individual dislocations but works with one +# homogenized mean-field density per grain. For simulations that are +# instantiated from EBSD datasets or crystal plasticity simulations +# individual values are available for each voxel that may be used as is +# for each voxel or may need a pre-processing of the data to coarse-grain +# material point-specific values to values averaged per deformed grain. +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Edge length of the material point that in SCORE +# is discretized via equisized cubic voxels. +# +# +# +# +# +# +# +# Criteria which enable to stop the simulation in a controlled manner. +# Whichever criterion is fulfilled first stops the simulation. +# Furthermore, numerical configuration required to achieve +# a stable numerical integration. +# +# +# +# Maximum recrystallized volume fraction. +# +# +# +# +# Maximum simulated physical time. +# +# +# +# +# Maximum number of iteration steps. +# +# +# +# +# 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. +# +# +# +# +# List of target values at which recrystallized volume fractions the state +# of the CA is evaluated and stored. The code documents summary statistics +# like recrystallized volume fraction for each iteration and the volume of each +# grain. Furthermore, snapshots of the microstructure are stored. +# These can take much disk space though because SCORE is able to evolve CA +# with up to :math:`1600^3` cells. Snapshot data document the current microstructure +# including the assignment of grains and cells surplus the state of the +# recrystallization front. +# +# Despite these front data make up for approximately one order of magnitude +# less cells than represented in the domain, more numerical data have to be +# collected for each cell in the front than just a grain identifier. +# +# +# +# +# +# +# +# Parameter which control the memory management +# of cells in the recrystallization front. +# +# +# +# Fraction of the total number of cells in the CA which +# should initially be allocated for offering storage for +# cells making up the recrystallization front. +# +# +# +# +# By how much more times should the already allocated memory +# be 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 or not. +# +# +# +# +# Target values at which recrystallized volume fraction the cache +# for cells in the recrystallization front will be defragmented +# on-the-fly. Defragmentation packs active cells closer into +# main memory to reduce cache misses in subsequent evaluations +# of the recrystallization front. +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 924291447c..253fb4907a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -72,7 +72,7 @@ NXmicrostructure_score_results(NXobject): Name of the program with which the simulation was performed. program(NX_CHAR): \@version: - environment(NXcollection): # NXcs_environment ? + environment(NXcollection): exists: optional doc: | Programs and libraries representing the computational environment @@ -365,7 +365,7 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (n_grains,) - recrystallization_front(NXmicrostructure_feature): # NXcollection ? + recrystallization_front(NXmicrostructure_feature): exists: recommended doc: | Details about those cells which in this time step represent the discrete @@ -430,3 +430,564 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: (n_front,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 609c1c0e42efe23249deed2b570fbab384ac818d1f711cb6f43319b5a4188e93 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# The total number of summary statistic log entries +# +# +# +# +# Number of boundaries of the bounding box or primitive about the computational +# 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 automata model. +# +# The SCORE cellular automata model for primary recrystallization is an example +# of a typical materials engineering application 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 nuclei during +# static recrystallization. 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>`_ +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Configuration file with the parameterization of the +# SCORE model that was used for this simulation. +# +# +# +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the simulation was started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the simulation ended. +# +# +# +# +# +# +# Name of the program with which the simulation was performed. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# The boundary conditions for each boundary: +# +# * 0 - undefined +# * 1 - open +# * 2 - periodic +# * 3 - mirror +# * 4 - von Neumann +# * 5 - Dirichlet +# +# +# +# +# +# +# +# Name of the boundaries. Left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. +# +# +# +# +# +# +# +# +# +# Documentation of the spatiotemporal evolution for each CA domain. +# +# SCORE is a hybrid parallelized code that can evolve multiple replicas +# in parallel. The set of replicas is distributed across MPI processes. +# Each such replica is then evolved via OpenMP multi-threading. +# +# +# +# +# Summary quantities which are the result of some post-processing of the snapshot data +# (averaging, integrating, interpolating) happening for practical and performance reasons +# during the simulation. Place used for storing descriptors from continuum mechanics +# and thermodynamics at the scale of the entire ROI. +# +# +# +# Evolution of the recrystallized volume fraction over time. +# +# +# +# +# +# +# +# +# +# +# Evolution of the physical time not to be confused with wall-clock time or +# profiling data. +# +# +# +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# +# +# +# Evolution of the simulated temperature over time. +# +# +# +# +# +# +# +# Recrystallized volume fraction. +# +# +# +# +# +# +# +# +# +# Which type of stress. +# +# +# +# +# +# +# +# Applied external stress tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of strain. +# +# +# +# +# Applied external strain tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of deformation gradient. +# +# +# +# +# +# +# +# Applied deformation gradient tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# Simulated temperature for this snapshot. +# +# +# +# +# Current recrystallized volume fraction (taking fractional infections into +# account). +# +# +# +# +# Target value for which a snapshot was requested for the recrystallized volume +# fraction. +# +# +# +# +# +# +# Index for each crystal whereby its metadata can be retrieved. +# +# +# +# +# +# +# +# +# +# Identifier of the OpenMP thread that processed this part of the grid. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Volume of each grain accounting also for partially transformed cells. +# +# +# +# +# +# +# +# +# Bunge-Euler angle triplets for each grain. +# +# +# +# +# +# +# +# +# Current value for the dislocation density as a measure of the remaining +# stored energy in assumed crystal defects inside each grain. +# +# +# +# +# +# +# +# Is the grain deformed. +# +# +# +# +# +# +# +# Is the grain recrystallized. +# +# +# +# +# +# +# +# +# Details about those cells which in this time step represent the discrete +# 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 that is modelled sweeping cells that +# make the discrete recrystallization front. +# +# +# +# +# +# +# +# The x, y, z 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. +# +# +# +# +# +# +# +# Identifier of the OpenMP thread processing each cell in the recrystallization +# front. +# +# +# +# +# +# +# +# Hint about the direction from which the cell was infected. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml index 53e829d225..d527b21885 100644 --- a/contributed_definitions/nyaml/NXphase.yaml +++ b/contributed_definitions/nyaml/NXphase.yaml @@ -41,3 +41,82 @@ NXphase(NXobject): (NXmicrostructure_pf): doc: | Instance names should use pf as a prefix. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c5a14f3c42585361926140d73c3e6ec8ac5b7ad519b624e554623ea2c041849c +# +# +# +# +# +# Base class to describe a (thermodynamic) phase as a component of a material. +# +# Instances of phases can be crystalline. +# +# +# +# Identifier for each phase. +# +# The value 0 is reserved for the unknown phase that represents the +# null-model (no sufficiently significant information available). +# In other words, the phase_name is n/a aka notIndexed. +# +# The identifier_phase value should match with the integer suffix of the +# group name which represents that instance in a NeXus/HDF5 file, i.e. +# if three phases were used e.g. 0, 1, and 2, three instances of +# :ref:`NXphase` named phase0, phase1, and phase2 should be stored +# in that HDF5 file. +# +# +# +# +# Given name as an alias for identifying this phase. +# +# If the identifier_phase is 0 and one would like to use +# the field name, the value should be n/a or notIndexed. +# +# +# +# +# +# +# +# Instance names should use microstructure as a prefix. +# +# +# +# +# Instance names should use ipf as a prefix. +# +# +# +# +# Instance names should use odf as a prefix. +# +# +# +# +# Instance names should use pf as a prefix. +# +# +# diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml index f5a5614d7c..8bd909cc84 100644 --- a/contributed_definitions/nyaml/NXroi.yaml +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -5,13 +5,58 @@ doc: | Do not confuse this base class with :ref:`NXregion`. type: group NXroi(NXobject): + # generic base classes (NXprocess): (NXdata): (NXimage): (NXspectrum): + # domain-specific customizations (NXem_img): (NXem_ebsd): (NXem_eds): (NXem_eels): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0d5c54aa964fe3be7058ec1295d958c2659d243c90a95d232f8bf4a8e26bad5d +# +# +# +# +# +# Base class to report on a region-of-interest of material analyzed or simulated. +# +# Do not confuse this base class with :ref:`NXregion`. +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXrotations.yaml b/contributed_definitions/nyaml/NXrotations.yaml index d4f3b8cf8d..e04302b5fe 100644 --- a/contributed_definitions/nyaml/NXrotations.yaml +++ b/contributed_definitions/nyaml/NXrotations.yaml @@ -192,7 +192,7 @@ NXrotations(NXobject): dim: (c, 3) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8c767a10ea4d5024333d74f4bb13db55b7f8a6ad9e390653b8b512dac30f4d22 +# 239aa437e4fe8b7fac66e7536590b07dbedff1e73a6f5361bff263fae970c716 # # # # -# Base class to detail a set of rotations, orientations, and disorientations. -# -# For getting a more detailed insight into the discussion of the -# parameterized description of orientations in materials science see: -# -# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ -# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ -# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ -# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ -# -# Once orientations are defined, one can continue to characterize the -# misorientation and specifically the disorientation. The misorientation describes -# the rotation that is required to register the lattices of two oriented objects -# (like crystal lattice) into a crystallographic equivalent orientation: -# -# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ +# Base class to detail a set of rotations, orientations, and disorientations. +# +# For getting a more detailed insight into the discussion of the +# parameterized description of orientations in materials science see: +# +# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ +# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ +# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ +# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ +# +# Once orientations are defined, one can continue to characterize the +# misorientation and specifically the disorientation. The misorientation describes +# the rotation that is required to register the lattices of two oriented objects +# (like crystal lattice) into a crystallographic equivalent orientation: +# +# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ +# +# The concepts of mis- and disorientation are relevant when analyzing the +# crystallography of interfaces. # # # -# Reference to an instance of :ref:`NXcoordinate_system` which contextualizes -# how the here reported parameterized quantities can be interpreted. +# Reference to an instance of :ref:`NXcoordinate_system` which contextualizes +# how the here reported parameterized quantities can be interpreted. # # # # -# Point group which defines the symmetry of the crystal. -# -# This has to be at least a single string. If crystal_symmetry is not -# provided, point group 1 is assumed. -# -# In the case that misorientation or disorientation fields are used -# and the two crystal sets resolve for phases with a different -# crystal symmetry, this field needs to encode two strings: -# The first string is for phase A. The second string is for phase B. -# An example of this most complex case is the description of the -# disorientation between crystals adjoining a hetero-phase boundary. +# Point group which defines the symmetry of the crystal. +# +# This has to be at least a single string. If crystal_symmetry is not +# provided, point group 1 is assumed. +# +# In the case that misorientation or disorientation fields are used +# and the two crystal sets resolve for phases with a different +# crystal symmetry, this field needs to encode two strings: +# The first string is for phase A. The second string is for phase B. +# An example of this most complex case is the description of the +# disorientation between crystals adjoining a hetero-phase boundary. # # # @@ -277,24 +280,24 @@ NXrotations(NXobject): # # # -# Point group which defines an assumed symmetry imprinted upon processing -# the material/sample which could give rise to or may justify to use a -# simplified description of rotations, orientations, misorientations, -# and disorientations via numerical procedures that are known as -# symmetrization. -# -# If sample_symmetry is not provided, point group 1 is assumed. -# -# The traditionally used symmetrization operations within the texture -# community in Materials Science, though, have become obsolete thanks -# to improvements in methods, software, and available computing power. +# Point group which defines an assumed symmetry imprinted upon processing +# the material/sample which could give rise to or may justify to use a +# simplified description of rotations, orientations, misorientations, +# and disorientations via numerical procedures that are known as +# symmetrization. +# +# If sample_symmetry is not provided, point group 1 is assumed. +# +# The traditionally used symmetrization operations within the texture +# community in Materials Science, though, have become obsolete thanks +# to improvements in methods, software, and available computing power. +# +# Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). # -# Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). -# -# In practice one often faces situations where indeed these assumed -# symmetries are anyway not fully observed, and thus an accepting of -# eventual inaccuracies just for the sake of reporting a simplified -# symmetrized description should be avoided. +# In practice one often faces situations where indeed these assumed +# symmetries are anyway not fully observed, and thus an accepting of +# eventual inaccuracies just for the sake of reporting a simplified +# symmetrized description should be avoided. # # # @@ -302,9 +305,9 @@ NXrotations(NXobject): # # # -# The set of rotations expressed in quaternion parameterization considering -# crystal_symmetry and sample_symmetry. Rotations which should be -# interpreted as antipodal are not marked as such. +# The set of rotations expressed in quaternion parameterization considering +# crystal_symmetry and sample_symmetry. Rotations which should be +# interpreted as antipodal are not marked as such. # # # @@ -313,11 +316,11 @@ NXrotations(NXobject): # # # -# The set of rotations expressed in Euler angle parameterization considering -# the same applied symmetries as detailed for the field rotation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the rotation -# conventions behind reference_frame to resolve which of the many possible -# Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# The set of rotations expressed in Euler angle parameterization considering +# the same applied symmetries as detailed for the field rotation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the rotation +# conventions behind reference_frame to resolve which of the many possible +# Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. # # # @@ -330,8 +333,8 @@ NXrotations(NXobject): # # # -# True for all those value tuples which have assumed antipodal symmetry. -# False for all others. +# True for all those value tuples which have assumed antipodal symmetry. +# False for all others. # # # @@ -339,10 +342,10 @@ NXrotations(NXobject): # # # -# The set of orientations expressed in quaternion parameterization and -# obeying symmetry for equivalent cases as detailed in crystal_symmetry -# and sample_symmetry. The supplementary field is_antipodal can be used -# to mark orientations with the antipodal property. +# The set of orientations expressed in quaternion parameterization and +# obeying symmetry for equivalent cases as detailed in crystal_symmetry +# and sample_symmetry. The supplementary field is_antipodal can be used +# to mark orientations with the antipodal property. # # # @@ -351,11 +354,11 @@ NXrotations(NXobject): # # # -# The set of orientations expressed in Euler angle parameterization following -# the same assumptions like for orientation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the rotation -# conventions behind reference_frame to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# The set of orientations expressed in Euler angle parameterization following +# the same assumptions like for orientation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the rotation +# conventions behind reference_frame to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. # # # @@ -367,13 +370,13 @@ NXrotations(NXobject): # orientation_axis_angle(NX_NUMBER):--> # # -# The set of misorientations expressed in quaternion parameterization -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. +# The set of misorientations expressed in quaternion parameterization +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. # -# The misorientation should not be confused with the disorientation, -# as for the latter the angular argument is expected to be the minimal -# obeying symmetries. +# The misorientation should not be confused with the disorientation, +# as for the latter the angular argument is expected to be the minimal +# obeying symmetries. # # # @@ -382,8 +385,8 @@ NXrotations(NXobject): # # # -# Misorientation angular argument (eventually signed) following the same -# symmetry assumptions as expressed for the field misorientation_quaternion. +# Misorientation angular argument (eventually signed) following the same +# symmetry assumptions as expressed for the field misorientation_quaternion. # # # @@ -391,8 +394,8 @@ NXrotations(NXobject): # # # -# Misorientation axis (normalized) and signed following the same -# symmetry assumptions as expressed for the field misorientation_angle. +# Misorientation axis (normalized) and signed following the same +# symmetry assumptions as expressed for the field misorientation_angle. # # # @@ -403,9 +406,9 @@ NXrotations(NXobject): # fundamental zone of SO3 for given crystal and sample symmetry--> # # -# The set of disorientations expressed in quaternion parameterization -# obeying symmetry operations for equivalent disorientations -# as defined by crystal_symmetry and sample_symmetry. +# The set of disorientations expressed in quaternion parameterization +# obeying symmetry operations for equivalent disorientations +# as defined by crystal_symmetry and sample_symmetry. # # # @@ -414,10 +417,10 @@ NXrotations(NXobject): # # # -# Disorientations angular argument (should not be signed, see -# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) -# following the same symmetry assumptions as expressed for the field -# disorientation_quaternion. +# Disorientations angular argument (should not be signed, see +# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) +# following the same symmetry assumptions as expressed for the field +# disorientation_quaternion. # # # @@ -425,8 +428,8 @@ NXrotations(NXobject): # # # -# Disorientations axis (normalized) following the same symmetry assumptions -# as expressed for the field disorientation_angle. +# Disorientations axis (normalized) following the same symmetry assumptions +# as expressed for the field disorientation_angle. # # # diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index e6aac9e0d8..27d42d0055 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -58,7 +58,7 @@ NXscanbox_em(NXcomponent): (NXcircuit): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3f374a059a0aa9d3a7e9cbf324b64fb43c925313c54d9bf84e3bc7561100d1ba +# 03e9a9a11e3ca9ebe548efc0e0d063132c488554d023069c1c2f446b6639a644 # # # +# +# +# Geometry of the unit cell quantified individually via parameter a. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter b. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter c. +# +# # # -# Geometry of the unit cell quantified via parameters alpha, beta, and gamma. +# Geometry of the unit cell quantified via parameters alpha, beta, and gamma. # # # # # +# +# +# Geometry of the unit cell quantified individually via parameter alpha. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter beta. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter gamma. +# +# # # -# Crystal system. -# -# For a crystal system in 2D space monoclinic is an exact synonym for oblique. -# For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. -# For a crystal system in 2D space tetragonal is an exact synonym for square. +# Crystal system. +# +# For a crystal system in 2D space monoclinic is an exact synonym for oblique. +# For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. +# For a crystal system in 2D space tetragonal is an exact synonym for square. # # # @@ -192,46 +221,47 @@ NXunit_cell(NXobject): # # # -# Laue group using International Table of Crystallography notation. +# Laue group using International Table of Crystallography notation. # # # # # -# Point group using International Table of Crystallography notation. +# Point group using International Table of Crystallography notation. # # # # -# Space group from the International Table of Crystallography notation. +# Space group from the International Table of Crystallography notation. # # # # -# 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 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. +# True if space group is considered a chiral one. +# False if space group is consider a non-chiral one. # # # # -# Area of the unit cell if dimensionality is 2. +# Area of the unit cell if dimensionality is 2. # # # # -# Volume of the unit cell if dimensionality is 3. +# Volume of the unit cell if dimensionality is 3. # # # +# # From 99e242684c586693d1ea3206cf396c4dbe9421e3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 21:32:24 +0200 Subject: [PATCH 28/57] Fixing incorrect nameType --- contributed_definitions/NXcg_polygon.nxdl.xml | 2 +- contributed_definitions/NXcg_tetrahedron.nxdl.xml | 2 +- contributed_definitions/NXem.nxdl.xml | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXcg_polygon.nxdl.xml b/contributed_definitions/NXcg_polygon.nxdl.xml index 7e7da8663a..7bb54ebba8 100644 --- a/contributed_definitions/NXcg_polygon.nxdl.xml +++ b/contributed_definitions/NXcg_polygon.nxdl.xml @@ -85,7 +85,7 @@ Individual storage of the mesh of each polygon. - + Individual storage of each polygon as a graph. diff --git a/contributed_definitions/NXcg_tetrahedron.nxdl.xml b/contributed_definitions/NXcg_tetrahedron.nxdl.xml index bbcca9edf8..4d333718d1 100644 --- a/contributed_definitions/NXcg_tetrahedron.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron.nxdl.xml @@ -68,7 +68,7 @@ Individual storage of each tetrahedron. - + Individual storage of each tetrahedron as a graph. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ccd0ddacb2..e158d0d2a4 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -708,7 +708,7 @@ - + - + From c1fe1f22d5bcd6008bd1100692c7af15e18b6089 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 21:34:40 +0200 Subject: [PATCH 29/57] Revert change in Makefile --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 49f4013564..2555d073aa 100644 --- a/Makefile +++ b/Makefile @@ -76,7 +76,7 @@ pdf :: cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.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 From d29e3b8ba91976ed45e76c883ddd7f177fff274a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 21:55:34 +0200 Subject: [PATCH 30/57] Updte custom dictionary cuz of new custom names --- .cspell/custom-dictionary.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.cspell/custom-dictionary.txt b/.cspell/custom-dictionary.txt index 4ec9355721..69e946635d 100644 --- a/.cspell/custom-dictionary.txt +++ b/.cspell/custom-dictionary.txt @@ -289,6 +289,7 @@ globulitic golay granularize granularized +granularization hagb halfwidth hashvalues @@ -508,6 +509,7 @@ Bergmann Berkels Bollmann Bonse +Borkowski Bravais Breen Britton @@ -525,6 +527,7 @@ Dimiduk Dimkou Doniach-Sunjic Dresselhaus +Dunin EIKOS Erlangen Ewald @@ -660,6 +663,7 @@ Voigt Volterra Voronoi Wellenreuther +Weppelman Windl Winkelmann Zaver From ca0c142145a436b5ab6f160b24c457486f7e7884 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 May 2025 22:01:48 +0200 Subject: [PATCH 31/57] Eliminate remaining references to NXcoordinate_system_set --- dev_tools/tests/test_nxdl_utils.py | 3 --- .../source/classes/contributed_definitions/apm-structure.rst | 2 +- manual/source/classes/contributed_definitions/em-structure.rst | 2 +- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index fab1bca078..a5a0527118 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -77,9 +77,6 @@ def test_get_node_at_nxdl_path(): elem=elem, ) assert node.attrib["type"] == "NX_NUMBER" - - node = nexus.get_node_at_nxdl_path("/ENTRY/coordinate_system_set", elem=elem) - assert node.attrib["type"] == "NXcoordinate_system_set" """ nxdl_file_path = local_dir / "../../contributed_definitions/NXiv_temp.nxdl.xml" diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 94bdc84c8e..d29d95bee8 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -39,7 +39,7 @@ Base Classes The following base classes are proposed to support modularizing the storage of pieces of information: - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: + :ref:`NXcoordinate_system` and :ref:`NXtransformations`: Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 096c81eee5..fb024dd95c 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -96,7 +96,7 @@ The following base classes are proposed to support modularizing the storage of p Contextualizing and defining definitions of reference frames and transformations of these and rotations and orientations defined within such reference frames: - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`, :ref:`NXtransformations`: + :ref:`NXcoordinate_system`, :ref:`NXtransformations`: Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another and respective transformations. From 39259416c9ca4cbb5d4cca0151d5997c3d574506 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 12 May 2025 11:12:05 +0200 Subject: [PATCH 32/57] Finished NXem --- contributed_definitions/NXem.nxdl.xml | 205 +++++++++++-------- contributed_definitions/nyaml/NXem.yaml | 251 +++++++++++++++--------- 2 files changed, 272 insertions(+), 184 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index e158d0d2a4..59c3bb77c0 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -114,18 +114,18 @@ start_time and end_time together. - - + + Collection of serialized resources associated with the experiment. Examples of such resources are files which are formatted using proprietary data models of technology partners as those generated by the control software of the microscope during the instrument session. - + - - + + @@ -350,9 +350,9 @@ How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from (improper) Tait-Bryan angles. @@ -391,16 +391,20 @@ - + - - + + + + + + + - Location of the origin of the processing_reference_frame. @@ -423,6 +427,7 @@ + Direction of the positively pointing x-axis base vector of the @@ -437,6 +442,7 @@ + Direction of the positively pointing y-axis base vector of the @@ -451,6 +457,7 @@ + Direction of the positively pointing z-axis base vector of the @@ -475,7 +482,6 @@ - Location of the origin of the sample_reference_frame. @@ -498,6 +504,7 @@ + Direction of the positively pointing x-axis base vector of the @@ -512,6 +519,7 @@ + Direction of the positively pointing y-axis base vector of the @@ -526,6 +534,7 @@ + Direction of the positively pointing z-axis base vector of the @@ -553,7 +562,6 @@ - Location of the origin of the detector_reference_frame. @@ -575,6 +583,7 @@ + Direction of the positively pointing x-axis base vector of the @@ -589,6 +598,7 @@ + Direction of the positively pointing y-axis base vector of the @@ -603,6 +613,7 @@ + Direction of the positively pointing z-axis base vector of the @@ -619,6 +630,7 @@ + @@ -645,7 +657,6 @@ - @@ -676,7 +687,18 @@ - + + + A spherical aberration corrector is a typical component in a transmission electron microscope. + Many instruments have only one, in this case the variadic suffix should be dropped. + If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, + corrector_cs2. + + + + Use specifically when there are multiple instances. + + @@ -690,7 +712,7 @@ - + @@ -711,11 +733,6 @@ - @@ -723,7 +740,7 @@ which components that microscope was built from--> - + @@ -747,6 +764,8 @@ which components that microscope was built from--> + + @@ -774,7 +793,7 @@ which components that microscope was built from--> - + @@ -783,7 +802,7 @@ which components that microscope was built from--> - + @@ -1159,7 +1178,7 @@ which components that microscope was built from--> - + @@ -1338,7 +1357,7 @@ basically optional use of NXaberration therein at least some value required--> - + @@ -1359,6 +1378,7 @@ basically optional use of NXaberration therein at least some value required--> + @@ -1418,18 +1438,21 @@ is required to provide such information in this way!--> - + - + - - - - + + + + + + @@ -1440,19 +1463,19 @@ is required to provide such information in this way!--> - + - - + + - + - - + + @@ -1460,10 +1483,10 @@ is required to provide such information in this way!--> - + - - + + - - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - + @@ -1551,7 +1582,7 @@ not wish to duplicate all payload data--> - + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index acea2d1a70..98c44067f8 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -81,19 +81,24 @@ NXem(NXobject): See docstring of the start_time field to see how to use the start_time and end_time together. - (NXcite): + citeID(NXcite): exists: ['min', '0', 'max', 'unbounded'] - (NXnote): + nameType: partial + noteID(NXnote): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial doc: | Collection of serialized resources associated with the experiment. Examples of such resources are files which are formatted using proprietary data models of technology partners as those generated by the control software of the microscope during the instrument session. type(NX_CHAR): + exists: recommended file_name(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): + exists: recommended userID(NXuser): exists: ['min', '0', 'max', 'unbounded'] nameType: partial @@ -291,9 +296,9 @@ NXem(NXobject): How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) according to convention 4 of reference ``_. - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from (improper) Tait-Bryan angles. enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] axis_angle_convention(NX_CHAR): doc: | @@ -307,19 +312,28 @@ NXem(NXobject): between different parametrizations/representations according to convention 6 of reference ``_. enumeration: [p_plus_one, p_minus_one] - (NXcoordinate_system): - exists: ['min', '1', 'max', 'unbounded'] + VARIADIC_reference_frame(NXcoordinate_system): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial alias(NX_CHAR): exists: optional type(NX_CHAR): - handedness(NX_CHAR): origin(NX_CHAR): + exists: recommended + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended processing_reference_frame(NXcoordinate_system): exists: recommended alias(NX_CHAR): exists: optional type(NX_CHAR): - handedness(NX_CHAR): origin(NX_CHAR): exists: recommended doc: | @@ -334,6 +348,7 @@ NXem(NXobject): enumeration: open_enum: true items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): x_direction(NX_CHAR): exists: recommended doc: | @@ -342,6 +357,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + y(NX_NUMBER): y_direction(NX_CHAR): exists: recommended doc: | @@ -350,6 +366,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + z(NX_NUMBER): z_direction(NX_CHAR): exists: recommended doc: | @@ -368,7 +385,6 @@ NXem(NXobject): alias(NX_CHAR): exists: optional type(NX_CHAR): - handedness(NX_CHAR): origin(NX_CHAR): exists: recommended doc: | @@ -383,6 +399,7 @@ NXem(NXobject): enumeration: open_enum: true items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): x_direction(NX_CHAR): exists: recommended doc: | @@ -391,6 +408,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + y(NX_NUMBER): y_direction(NX_CHAR): exists: recommended doc: | @@ -399,6 +417,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + z(NX_NUMBER): z_direction(NX_CHAR): exists: recommended doc: | @@ -420,7 +439,6 @@ NXem(NXobject): alias(NX_CHAR): exists: optional type(NX_CHAR): - handedness(NX_CHAR): origin(NX_CHAR): exists: recommended doc: | @@ -434,6 +452,7 @@ NXem(NXobject): enumeration: open_enum: true items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): x_direction(NX_CHAR): exists: recommended doc: | @@ -442,6 +461,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + y(NX_NUMBER): y_direction(NX_CHAR): exists: recommended doc: | @@ -450,6 +470,7 @@ NXem(NXobject): enumeration: open_enum: true items: [north, east, south, west, in, out] + z(NX_NUMBER): z_direction(NX_CHAR): exists: recommended doc: | @@ -460,6 +481,7 @@ NXem(NXobject): items: [north, east, south, west, in, out] measurement(NXem_measurement): exists: optional + # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em instrument(NXinstrument_em): name(NX_CHAR): exists: recommended @@ -491,8 +513,6 @@ NXem(NXobject): emitter_type(NX_CHAR): probe(NX_CHAR): exists: optional - - # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -529,8 +549,18 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - corrector_cs(NXcorrector_cs): - exists: ['min', '0', 'max', '1'] + corrector_csID(NXcorrector_cs): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + doc: | + A spherical aberration corrector is a typical component in a transmission electron microscope. + Many instruments have only one, in this case the variadic suffix should be dropped. + If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, + corrector_cs2. + name(NX_CHAR): + exists: recommended + doc: | + Use specifically when there are multiple instances. fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): @@ -547,7 +577,7 @@ NXem(NXobject): exists: recommended biprismID(NXcomponent): nameType: partial - exists: ['min', '0', 'max', '1'] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): @@ -578,12 +608,6 @@ NXem(NXobject): exists: ['min', '0', 'max', 'unbounded'] ibeam_column(NXibeam_column): exists: ['min', '0', 'max', '1'] - - # there are tri-beam SEMs, but with a laser for which one should add NXsource - # fabrication groups often were not made recommended or required because in practice - # often scientific groups buy a commercial microscope for which the type and serial number - # of the microscope (as in the top-level fabrication of instrument) suffices to recover - # which components that microscope was built from fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -592,7 +616,7 @@ NXem(NXobject): exists: recommended ion_source(NXsource): emitter_type(NX_CHAR): - probe(NXatom): + probe(NXion): fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -622,6 +646,8 @@ NXem(NXobject): monochromatorID(NXmonochromator): nameType: partial exists: ['min', '0', 'max', 'unbounded'] + type(NX_CHAR): + name(NX_CHAR): fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -660,7 +686,7 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - stage(NXmanipulator): + stageID(NXmanipulator): exists: ['min', '0', 'max', 'unbounded'] design(NX_CHAR): exists: recommended @@ -672,7 +698,7 @@ NXem(NXobject): model(NX_CHAR): serial_number(NX_CHAR): exists: recommended - nanoprobe(NXmanipulator): + nanoprobeID(NXmanipulator): exists: optional fabrication(NXfabrication): exists: recommended @@ -1045,8 +1071,8 @@ NXem(NXobject): exists: recommended voltage(NX_NUMBER): exists: recommended - corrector_cs(NXcorrector_cs): - exists: ['min', '0', 'max', '1'] + corrector_csID(NXcorrector_cs): + exists: ['min', '0', 'max', 'unbounded'] applied(NX_BOOLEAN): exists: recommended tableauID(NXprocess): @@ -1250,7 +1276,7 @@ NXem(NXobject): actuatorID(NXactuator): nameType: partial exists: ['min', '0', 'max', 'unbounded'] - stage(NXmanipulator): + stageID(NXmanipulator): exists: ['min', '0', 'max', 'unbounded'] design(NX_CHAR): exists: recommended @@ -1273,6 +1299,8 @@ NXem(NXobject): Nominal voltage of the heater. heater_power(NX_NUMBER): unit: NX_POWER + nanoprobeID(NXmanipulator): + exists: ['min', '0', 'max', 'unbounded'] optics(NXoptical_system_em): exists: recommended simulation(NXem_simulation): @@ -1336,20 +1364,25 @@ NXem(NXobject): nameType: partial exists: ['min', '1', 'max', 'unbounded'] imaging_mode(NX_CHAR): - (NXmicrostructure): - exists: optional + # (NXmicrostructure): + # exists: optional ebsd(NXem_ebsd): exists: optional gnomonic_reference_frame(NXcoordinate_system): - exists: optional + exists: recommended alias(NX_CHAR): exists: optional type(NX_CHAR): - handedness(NX_CHAR): origin(NX_CHAR): + x(NX_NUMBER): x_direction(NX_CHAR): + exists: recommended + y(NX_NUMBER): y_direction(NX_CHAR): + exists: recommended + z(NX_NUMBER): z_direction(NX_CHAR): + exists: recommended pattern_center(NXprocess): exists: recommended x_boundary_convention(NX_CHAR): @@ -1361,17 +1394,23 @@ NXem(NXobject): depends_on(NX_CHAR): source(NXnote): type(NX_CHAR): + exists: recommended file_name(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): + exists: recommended simulation(NXprocess): exists: optional depends_on(NX_CHAR): source(NXnote): type(NX_CHAR): + exists: recommended file_name(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): + exists: recommended calibration(NXprocess): exists: recommended indexing(NXprocess): @@ -1382,10 +1421,12 @@ NXem(NXobject): source(NXnote): exists: optional type(NX_CHAR): + exists: recommended file_name(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): - + exists: recommended # per scan point quantities (identifier_phase, matching_phase, positions, etc.) # just using the implicit optional, for the database example in NOMAD we do # not wish to duplicate all payload data @@ -1396,54 +1437,58 @@ NXem(NXobject): exists: recommended number_of_scan_points(NX_UINT): unit_cell(NXunit_cell): - a_b_c(NX_NUMBER): - alpha_beta_gamma(NX_NUMBER): + a(NX_NUMBER): + b(NX_NUMBER): + c(NX_NUMBER): + alpha(NX_NUMBER): + beta(NX_NUMBER): + gamma(NX_NUMBER): space_group(NX_CHAR): - # foreseen place for phase-specific texture and microstructure representations and statistics - IPF(NXmicrostructure_ipf): - nameType: any - exists: recommended - color_model(NX_CHAR): - projection_direction(NX_NUMBER): - map(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - axis_z(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - legend(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - ODF(NXmicrostructure_odf): - nameType: any - exists: optional - PF(NXmicrostructure_pf): - nameType: any - exists: optional - (NXmicrostructure): - exists: optional + # ipfID(NXmicrostructure_ipf): + # nameType: partial + # exists: ['min', '1', 'max', 'unbounded'] + # color_model(NX_CHAR): + # projection_direction(NX_NUMBER): + # map(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_UINT): + # nameType: partial + # title(NX_CHAR): + # exists: recommended + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # axis_z(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # legend(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_UINT): + # nameType: partial + # title(NX_CHAR): + # exists: recommended + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # \@long_name(NX_CHAR): + # odfID(NXmicrostructure_odf): + # nameType: partial + # exists: optional + # pfID(NXmicrostructure_pf): + # nameType: partial + # exists: optional + # microstructureID(NXmicrostructure): + # nameType: partial + # exists: optional roi(NXdata): exists: recommended \@signal(NX_CHAR): @@ -1453,6 +1498,7 @@ NXem(NXobject): title(NX_CHAR): exists: recommended descriptor(NX_CHAR): + exists: recommended data(NX_NUMBER): axis_z(NX_NUMBER): exists: optional @@ -1478,7 +1524,7 @@ NXem(NXobject): axis_energy(NX_CHAR): \@long_name(NX_CHAR): atom_types(NX_CHAR): - (NXimage): + ELEMENT_SPECIFIC_MAP(NXimage): exists: ['min', '0', 'max', '118'] iupac_line_candidates(NX_CHAR): exists: recommended @@ -1506,7 +1552,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 434eb9b819d62bf4c4232ffe882c157f61c386a61070dc237fd860af4e2ff5c4 +# 48daf4f65abc939963c87bd2719b27a562e819f3eda0e01aa7bea905d9370d08 # # # Base class for an electro-magnetic lens or a compound lens. - + For :ref:`NXtransformations` the origin of the coordinate system is placed in the center of the lens (its polepiece, pinhole, or another point of reference). The origin should be specified in the :ref:`NXtransformations`. - - For details of electro-magnetic lenses in the literature see e.g. + + For details of electro-magnetic lenses in the literature see e.g. * `L. Reimer: Scanning Electron Microscopy <https://doi.org/10.1007/978-3-540-38967-5>`_ * `P. Hawkes: Magnetic Electron Lenses <https://link.springer.com/book/10.1007/978-3-642-81516-4>`_ * `Y. Liao: Practical Electron Microscopy and Database <https://www.globalsino.com/EM/>`_ - @@ -51,7 +50,7 @@ with other research fields (MPES, XPS, OPT) could be useful--> Ideally, use instances of ``identifierNAME`` to point to a resource that provides further details. - + If such a resource does not exist or should not be used, use this free text, although it is not recommended. @@ -61,8 +60,8 @@ with other research fields (MPES, XPS, OPT) could be useful--> 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). - + values for 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 @@ -75,7 +74,7 @@ with other research fields (MPES, XPS, OPT) could be useful--> 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. @@ -84,7 +83,7 @@ with other research fields (MPES, XPS, OPT) could be useful--> Excitation voltage of the lens. - + For dipoles it is a single number. For higher order multipoles, it is an array. @@ -92,7 +91,7 @@ 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. diff --git a/base_classes/nyaml/NXlens_em.yaml b/base_classes/nyaml/NXlens_em.yaml index 8dbddf0f0f..a28ed94e2b 100644 --- a/base_classes/nyaml/NXlens_em.yaml +++ b/base_classes/nyaml/NXlens_em.yaml @@ -36,7 +36,7 @@ NXlens_em(NXcomponent): 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). + values for users. Although this value does not document the exact physical voltage or excitation, it can still give useful context to reproduce the lens @@ -75,7 +75,7 @@ NXlens_em(NXcomponent): enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# de9edcc2aff19a8e0a5b467b2cd2a56804492f46a992db47242688b245bc7e3c +# da0d34149a5d7ee0128593d6cb32345907b6d2d1a556af5dc1c7be7018c7017e # # # # @@ -129,7 +128,7 @@ NXlens_em(NXcomponent): # # Ideally, use instances of ``identifierNAME`` to point to a resource # that provides further details. -# +# # If such a resource does not exist or should not be used, use this free text, # although it is not recommended. # @@ -139,8 +138,8 @@ NXlens_em(NXcomponent): # 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). -# +# values for 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 @@ -153,7 +152,7 @@ NXlens_em(NXcomponent): # 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. # @@ -162,7 +161,7 @@ NXlens_em(NXcomponent): # # # Excitation voltage of the lens. -# +# # For dipoles it is a single number. # For higher order multipoles, it is an array. # @@ -170,7 +169,7 @@ NXlens_em(NXcomponent): # # # Excitation current of the lens. -# +# # For dipoles it is a single number. # For higher-order multipoles, it is an array. # diff --git a/contributed_definitions/NXatom.nxdl.xml b/contributed_definitions/NXatom.nxdl.xml index 698d8c469b..40051eb539 100644 --- a/contributed_definitions/NXatom.nxdl.xml +++ b/contributed_definitions/NXatom.nxdl.xml @@ -42,7 +42,7 @@ Atoms in the set may be bonded. The set may have a net charge to represent an ion. - Ions can be molecular ions. + An ion can be a molecular ion. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 59c3bb77c0..a4f96c2e91 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -793,7 +793,7 @@ - + @@ -802,7 +802,7 @@ - + @@ -1178,7 +1178,7 @@ - + @@ -1357,7 +1357,7 @@ basically optional use of NXaberration therein at least some value required--> - + @@ -1378,7 +1378,7 @@ basically optional use of NXaberration therein at least some value required--> - + @@ -1441,7 +1441,7 @@ is required to provide such information in this way!--> +exists: optional--> @@ -1506,49 +1506,49 @@ not wish to duplicate all payload data--> +nameType: partial +exists: optional--> diff --git a/contributed_definitions/NXinstrument_em.nxdl.xml b/contributed_definitions/NXinstrument_em.nxdl.xml index 7e82e3e8b4..fb955be89f 100644 --- a/contributed_definitions/NXinstrument_em.nxdl.xml +++ b/contributed_definitions/NXinstrument_em.nxdl.xml @@ -132,8 +132,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. diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 779cea7584..50e788acf4 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -92,7 +92,7 @@ The array is stored matching the order of nuclide_hash. - + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index fb65f16a47..f41afb4a73 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -23,8 +23,7 @@ --> - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. + Base class to describe the use of manipulators and sample stages. @@ -43,9 +42,9 @@ - Cryostat for cooling the sample. + Cryostat for cooling the sample (and, potentially, the whole manipulator). - + @@ -61,7 +60,7 @@ In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + recorded with time stamps, this is an array of temperature setpoints. @@ -96,7 +95,7 @@ Device to heat the sample. - + @@ -158,9 +157,9 @@ - Actuator applying a voltage to sample and sample holder. + Actuator applying a voltage between sample holder and sample. - + @@ -208,17 +207,18 @@ - Any additional actuators on the manipulator. + Any additional actuator on the manipulator used to control an external + condition. - Any additional sensors on the manipulator. + Any additional sensors on the manipulator used to monitor an external condition. - Class to describe the motors that are used in the manipulator + Class to describe the motors that are used in the manipulator. diff --git a/contributed_definitions/nyaml/NXatom.yaml b/contributed_definitions/nyaml/NXatom.yaml index c1067f7343..d8614f4541 100644 --- a/contributed_definitions/nyaml/NXatom.yaml +++ b/contributed_definitions/nyaml/NXatom.yaml @@ -4,7 +4,7 @@ doc: | Atoms in the set may be bonded. The set may have a net charge to represent an ion. - Ions can be molecular ions. + An ion can be a molecular ion. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -99,7 +99,7 @@ NXatom(NXobject): dim: (n_pos,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a29e115b8616c18332086bb4385318262888a3fdc41aed7e560d6b9b554bf93e +# fc189c70eeb19f2dadb12b90700cfeef10148baf87fd6e71874db0941aeb5aaf # # # # # # @@ -2211,7 +2221,6 @@ NXem(NXobject): # # # -# # # # @@ -2242,7 +2251,18 @@ NXem(NXobject): # # # -# +# +# +# A spherical aberration corrector is a typical component in a transmission electron microscope. +# Many instruments have only one, in this case the variadic suffix should be dropped. +# If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, +# corrector_cs2. +# +# +# +# Use specifically when there are multiple instances. +# +# # # # @@ -2256,7 +2276,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2277,11 +2297,6 @@ NXem(NXobject): # # # -# # # # @@ -2289,7 +2304,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2313,6 +2328,8 @@ NXem(NXobject): # # # +# +# # # # @@ -2340,7 +2357,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2349,7 +2366,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2725,7 +2742,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2904,7 +2921,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2925,6 +2942,7 @@ NXem(NXobject): # # # +# # # # @@ -2984,18 +3002,21 @@ NXem(NXobject): # # # -# # # +# # -# +# # # -# # -# -# -# +# +# +# +# +# +# # # # @@ -3006,19 +3027,19 @@ NXem(NXobject): # # # -# +# # -# -# +# +# # # # # # -# +# # -# -# +# +# # # # @@ -3026,10 +3047,10 @@ NXem(NXobject): # # # -# +# # -# -# +# +# # # -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# # +# # # # # # -# +# # # # @@ -3117,7 +3146,7 @@ NXem(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 65af168c42..1e069c37a4 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -104,7 +104,7 @@ NXem_eds(NXprocess): description(NX_CHAR): doc: | Discouraged free-text field to add additional information. - iupac_line_candidate(NX_CHAR): + iupac_line_candidates(NX_CHAR): doc: | Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that documents which elements and their specific lines are theoretically located within diff --git a/contributed_definitions/nyaml/NXinstrument_em.yaml b/contributed_definitions/nyaml/NXinstrument_em.yaml index a2c6a4700e..0d37a181b4 100644 --- a/contributed_definitions/nyaml/NXinstrument_em.yaml +++ b/contributed_definitions/nyaml/NXinstrument_em.yaml @@ -56,7 +56,7 @@ NXinstrument_em(NXinstrument): Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. scan_controller(NXscanbox_em): - stage(NXmanipulator): + stageID(NXmanipulator): doc: | Stages in an electron microscope are multi-functional devices. @@ -166,7 +166,7 @@ NXinstrument_em(NXinstrument): dimensions: rank: 1 dim: (3,) - nanoprobe(NXmanipulator): + nanoprobeID(NXmanipulator): doc: | In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index 28748c9cc6..1a6fa97a17 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -55,7 +55,7 @@ NXion(NXatom): The array is stored matching the order of nuclide_hash. dimensions: rank: 2 - dim: (n_ivecmax, 2) + dim: (n_ivec_max, 2) mass_to_charge_range(NX_NUMBER): unit: NX_ANY doc: | @@ -69,7 +69,7 @@ NXion(NXatom): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6628af1c8c82bda25cfcee865a22cb869cc77412c9459d666475b97f23d911e2 +# a1dc78983139da8e01cd046802c165bc548480ccfb287e40c9bd4e1f188aa59a # # # # # -# Extension of NXpositioner to include fields to describe the use of manipulators -# in photoemission experiments. +# Base class to describe the use of manipulators and sample stages. # # # @@ -181,9 +180,9 @@ NXmanipulator(NXcomponent): # # # -# Cryostat for cooling the sample. +# Cryostat for cooling the sample (and, potentially, the whole manipulator). # -# +# # # # @@ -199,7 +198,7 @@ NXmanipulator(NXcomponent): # # # In the case of an experiment in which the temperature is changed and the setpoints are -# recorded with time stamps, this is an array of length m of temperature setpoints. +# recorded with time stamps, this is an array of temperature setpoints. # # # @@ -234,7 +233,7 @@ NXmanipulator(NXcomponent): # # Device to heat the sample. # -# +# # # # @@ -296,9 +295,9 @@ NXmanipulator(NXcomponent): # # # -# Actuator applying a voltage to sample and sample holder. +# Actuator applying a voltage between sample holder and sample. # -# +# # # # @@ -346,17 +345,18 @@ NXmanipulator(NXcomponent): # # # -# Any additional actuators on the manipulator. +# Any additional actuator on the manipulator used to control an external +# condition. # # # # -# Any additional sensors on the manipulator. +# Any additional sensors on the manipulator used to monitor an external condition. # # # # -# Class to describe the motors that are used in the manipulator +# Class to describe the motors that are used in the manipulator. # # # From 83f6dde14b680e46628a2d314280404d150e5fd3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 12 May 2025 11:17:32 +0200 Subject: [PATCH 34/57] Make remaining nxdls that were not yet in sync --- contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXinstrument_em.nxdl.xml | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index caa87c3243..530c33037c 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -161,7 +161,7 @@ Discouraged free-text field to add additional information. - + Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that documents which elements and their specific lines are theoretically located within diff --git a/contributed_definitions/NXinstrument_em.nxdl.xml b/contributed_definitions/NXinstrument_em.nxdl.xml index fb955be89f..7da8346ca7 100644 --- a/contributed_definitions/NXinstrument_em.nxdl.xml +++ b/contributed_definitions/NXinstrument_em.nxdl.xml @@ -88,7 +88,7 @@ - + Stages in an electron microscope are multi-functional devices. @@ -132,7 +132,8 @@ * `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. @@ -211,7 +212,7 @@ in a particular narrow community which work with that particular microscope--> - + In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and From 4f8a2e7379b28d6536b285c0f8af5692def5ab28 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 1 Jul 2025 09:21:46 +0200 Subject: [PATCH 35/57] Cleaned nyaml and regenerated them from scratch --- contributed_definitions/nyaml/NXem_eds.yaml | 4 ++-- contributed_definitions/nyaml/NXinstrument_em.yaml | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 1e069c37a4..9866cd52ae 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -133,7 +133,7 @@ NXem_eds(NXprocess): contributes to the intensity of the EDS map. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cae12797615c334d3bf86e6501d460012fe7e426820d8a9b436f8659e114c3a5 +# 3903897979b6ea01fe3d2ffbcfc0642fe9593e9419111b1d5de3f419609f3505 # # # + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of hit qualities, the so-called hit types, distinguished. + + + + + Number of delay-line-detector (DLD) wires of the detector. + + + + + Number of bins used in the mass-to-charge-state-ratio spectrum. + + + + + Number of pulses collected in between start_time and end_time resolved by an + instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of + ions included in the reconstructed volume if the application definition is used + to store results of an already reconstructed dataset. + + + + + Number of pulses returned by the hit_finding algorithm. + Neither necessarily equal to p nor to n. + + + + + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process, the so-called + evaporation_id. This identifier must not be confused with the pulse_id. + This value is typically smaller than both p and p_out. + + + + + Number of mass resolution values. + + + + + Application definition for real or simulated atom probe and field-ion microscopy experiments. + + Atom probe tomography and field-ion microscopy are methods for characterizing materials + through induced controlled extraction of individual atoms as ions and molecular ions from + a sharp needle-shaped specimen. + + Offering isotopic and nanometer-scale resolution, atom probe data enable quantification of + local chemical composition and computing of volumetric reconstructions which are models for + the atomic architecture of the small specimen volume analyzed. These reconstructions provide + input for characterization of atomic segregation at crystal defects. The term microstructural features + is considered as a narrow synonym for crystal defects. + + The aim of the NXapm application definition is to provide a general yet specific enough + solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments. + + Before summarizing the design of the base classes and the parts of the NXapm application definition, + it is worthwhile to recall and distinguish concepts that are related to atom extraction + events and the molecular ions that are frequently generated by the sequence of events: + + * An atom probe instrument uses laser or voltage pulsing events to trigger ion extraction events. + * These ions are accelerated in an electric field towards a position-sensitive detector system. + Physical events and corresponding signal on this detector is triggered by an ion hitting the detector. + Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. + * Note that only a part the specimen volume can be measured and finite detection efficiency means that + not all atoms in the measured volume will be detected. Neutral atoms can escape detection. Some ions + escape detection because they hit into walls of the analysis_chamber. + + Raw data are typically processed as follows: + + * Detector pulses and their timing are processed and discriminated into signal events of different quality levels. + High quality events might be considered in further processing to identify the corresponding molecular ion + and its original position in the reconstructed volume. + * Signal calibration and filtering steps are applied to convert raw time-of-flight data to calibrated + mass-to-charge state ratio values and obtain calibrated impact positions on the detector. + * Ranging and identifying an ion that corresponds to each detector event. + Isotopic abundance and theoretical models inform these ranging algorithms. + * Finally, such selected ion impact positions and iontypes are used to compute a reconstructed volume of + the specimen using backprojection algorithms. In effect, an atom probe measurement is a combination of + a data acquisition and a data analysis workflow. + + Not only in AMETEK/Cameca's APSuite/IVAS software, which the majority of atom probers use, these concepts + are well distinguished. However, the algorithms used to transform correlations between pulses and physical + events into actual events, the so-called detector hits of ions, is a proprietary one. This algorithm is also + referred to as the hit finding algorithm. + + Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting + schema where the course of the specimen evaporation is documented such that quantities are a function of + evaporation_id i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. + That is the evaporation_id values take the role of an implicit time and course of the experiment given that + ion extraction physically is a sequential process. + + This application definition includes fields that the atom probe community has decided to represent best practices + for reporting atom probe measurements. Exemplar mapping tables are provided for documents that reported these + best practices to translate technical term into concepts of the NXapm application definition. + + *The NeXus application definition NXapm defines a hierarchical data model with ten building blocks:* + + The data model represents a tree of concepts. The tree is constructed from groups of concepts representing + the branches, together with fields and attributes representing leaves. NXapm is defined by composing and + specializing base classes into the following ten categories: + + - The field ``definition`` specifies that the data schema is NXapm. In combination with + administrative metadata such as the attribute ``NeXus_version`` provided by :ref:`NXroot` this + specifies which version of NXapm the instance data in a NeXus/HDF5 file are compliant with. + - The fields ``run_number``, ``experiment_alias``, ``experiment_description`` and + the group ``userID`` provide concepts for storing organizational metadata that + contextualize the work within the research workflow and humans involved in this. + - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. + - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations or notes + that are associated with the data, i.e. other artifacts that are deemed relevant when reporting about + a measurement or simulation. These groups are useful when NXapm is used as a serialization format for + technology-partner-agnostic archival of data and metadata that have been collected during a session with + an atom probe instrument. The terms run and session are understood as exact synonyms that refer to an + uninterrupted period of measurement. Resuming measurement on a specimen after an interruption is viewed + as a new run and the new data should not be appended to the previous run, but written to either a new NXentry, + or a new file. Removing the specimen from the instrument is an interruption. Changing evaporation conditions + while the specimen is remains in the analysis_chamber and resuming thereafter the measurement + is not considered as an interruption. It is a common strategy to probe the evaporation process for different + instrument parameters. Each individual collection should then though be stored in an own NXevent_data_apm + group. Parking the specimen to the buffer_chamber and resuming the measurement at a later stage is an interruption. + During a run, the microscope is used for a certain amount of time to characterize a single specimen. + - The groups ``sample`` and ``specimen`` provide concepts for storing metadata about the sample and the specimen, + i.e. the smaller part that was removed from the sample to be measured in the atom probe session. + The term "tip" in the context of atom probe research is considered jargon. + Specimen is an exact synonym for tip. + - The field ``operation_mode`` and group ``measurement`` provides concepts that + are useful for describing a measurement during a session with an atom probe or field-ion microscope. + This includes the chain of events of data and metadata that were collected during such a session. + - The group ``simulation`` provides concepts that are useful for describing a simulation of an + atom extraction, ionization, and ion trajectory simulation. Combined with ``measurement`` + this provides a data schema for defining a digital twin of the instrument and its setup. + - The groups ``consistent_rotations``, and ``NAMED_reference_frame`` provide concepts for + reporting coordinate systems (frames of reference) and rotation conventions that clarify how data + should be interpreted specifying the rotation of orientable objects in the microscope, its components, + or of crystals and crystal defects in the material analyzed. + - The group ``atom_probeID`` provides concepts for the computational workflows that were + used to convert raw detector data into reconstructed ion positions and documentation of + ranging definitions made. + - The group ``profiling`` provides concepts for reporting computational details such as + programs and libraries used, for documenting the libraries of virtual environments such as those used + by conda or python virtual environment, including details about the computing hardware used, and + documenting capabilities for performance analyses and benchmarking of the software or its parts. + + *Design choices:* + + Given that most atom probe instruments across the globe were built by AMETEK/Cameca and are delivered + with the AP Suite/IVAS software there is some homogeneity in how a measurement is performed and which data + artifacts and algorithms used for data processing. Complementary use of open-source software specifically for + the reconstruction, ranging, and later data processing stages contributes to a landscape of multiple tools in use. + Therefore, communication of atom probe research differs between user groups. This holds even more so true + for the sub community in atom probe which study physical mechanisms involved during ionization to the point that + here that almost each research work defines different simulation tools with different types of data artifacts. + + NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to + offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended + but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex + use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the + optional group ``measurement`` with its required child ``measurement/instrument``: + Users which report simulations are not forced to document the instrument but users which have characterized + a specimen are motivated to report about the instrument. They are though not necessarily required to report all + the details of the instruments' components because the design pattern is applied recursively. + + *NXapm distinguishes and stores instance data based on how long they remain unchanged:* + + ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. + The first group is designed for storing metadata about the instrument that do not change over the course of the session. + Examples are the name of the technology partner who built the microscope or whether a laser or voltage pulser + and reflectron exists or not. The second group is designed for metadata and data that are collected during + the session with the instrument. These, are stored as instances of ``measurement/eventID``, + events that can be time-stamped individually. + Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose is to + store those specific state and settings of the instrument that was present during the collection of the event. + Thereby, changing conditions such as compaigns with different target detection rate can be stored. + + Noteworthy, such an approach of the atom probe detecting groups of events and storing these as groups has also + been in use in the proprietary software via CamecaRoot, a set of customized data structures and file formats that use + the CernRoot library. By virtue of design this reduces unnecessary repetition of metadata stored in the first group. + + ``atom_probeID`` offer classes for the each task relevant task in the data processing pipeline that converts raw detector + event data to calibrated mass-to-charge-state-ratio values and hit_position on the detector. These include + ``initial_specimen``, and ``final_specimen`` locations for storing images of the specimen prior/after the measurement as + considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the + hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about + to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations + and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the + conversion from time-of-flight to mass-to-charge-state-ratio values. + + Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how + from all the previous sources of input one can compute a reconstructed volume, and apply peak fitting routines on the + mass-to-charge-state-ratio histogram to label ions, i.e. range them for their isotopic identity. + Group ``atom_probeID/reconstruction/naive_discretization`` offers a standardized way to report simple + three-dimensional histograms. Group ``atom_probeID/ranging/peak_identification/ionID`` and its + complementing group ``atom_probeID/ranging/peak_identification/ionID/charge_state_analysis`` + solves the issue that the ranging definitions in classical file formats are not reported for always for their isotopic identity + and charge state. The field ``atom_probeID/ranging/peak_identification/iontypes`` provides a place for + storing a compact representation of the results of each ranging definition made at the level of each ion. + + *The compatibility of NXapm and NXem:** + + The design of NXapm mirrors that of :ref:`NXem`. This was an intentional choice to support the increasingly stronger connection between + these two materials characterization methods, especially in light of recent advances in the direct coupling of atom probe and + transmission electron microscopes and scanning transmission electron microscopes. + + + + + + + + + + + The configuration of the software that was used to generate this NeXus file. + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + The identifier whereby the experiment is referred to in the control software. + + It is common practice in atom probe research to refer to a measurement on a single + specimen as a run. When working with AMETEK/Cameca instruments it is a common + practice also to store all data associated with such a run in files whose name + is composed from a prefix that details the type of instrument (e.g. R5076) followed + by the run_number. These filenames are often used as the specimen_name or + experiment_identifier. The terms run and session are understood as exact synonyms. + + For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, + or the instruments at GPM in Rouen, use the identifier which matches + best conceptually 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; provided these + RHIT or HITS files respectively are stored alongside a data artifact. + With NXapm the RHIT or HITS can be stored via NXnote in the + hit_finding algorithm section. + + 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. Such interrupted runs + should be stored as individual :ref:`NXentry` instances in one NeXus file. + + + + + Alias or short name which scientists can use to refer to this experiment. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into the field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the atom probe session started. If the exact duration of + the measurement is not relevant, start_time only should be used. + + The start_time is required in order to ensure that at least one point in time + is provided for full temporal context to a measurement and simulation + when writing instance data using NXapm. Otherwise, the instance data + can not be sorted in order or even placed in a logical sequence to other + steps of the research workflow, which would disallow using functionalities + in research data management systems that rely on temporal context. + + Specifying start_time and end_time is useful for capturing more detailed + bookkeeping 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. For this + purpose the :ref:`NXevent_data_apm` instance should be used. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the atom probe session ended. + + Writing the end_time can be a tricky in practice. If written at the start + of the experiment, it can only be an estimate. If written at the end, there + is the risk for having the computer crash or lose power. The absence of + end_time should not be interpreted as that the experiment was aborted. + Only, the field ``status`` should be used for communicating such abortion. + + + + + How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime + + + + + + + + + + + + + + What type of atom probe experiment is performed to inform research data management + systems and allow filtering: + + * apt are experiments where the analysis_chamber has no imaging gas. + Experiments with LEAP instruments are typically with this operation_mode. + * 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. + Few experiments of this type have been performed, as it can be detrimental + to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). + + + + + + + + + + + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + In NXapm, a measurement is performed on a specimen. Since APM specimens + are very small, they are typically cut from a larger object with some + scientific significance, which NXapm refers to as a sample. + + + + + False, if the sample is a real one. + True, if the sample is a virtual one. + + + + + Given name/alias for the sample. + + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + + If the specimen does not contain many crystals average values + might be an unreliable descriptor. + + Reporting a grain size may be useful though as it allows + judging if specific features are expected to be found in the + detector hit map. + + + + + Magnitude of the standard deviation of the grain_diameter. + + + + + An array of elapsed time, the independent axis, of a time-temperature curve. + + This field can be used in combination with heat_treatment_temperature and + heat_treatment_temperature_errors as well as heat_treatment_quenching_rate + and heat_treatment_quenching_rate_errors respectively. In this case, these fields + should also be stored as an array with the same dimensions as heat_treatment_time + to store the dependant axes of a time-temperature curve as well as its first derivative. + + + + + If heat_treatment_time is absent, 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 a documentation of the annealing + treatment as a function of time is available one should better + rely on this information and have it stored alongside the NeXus file. + + If heat_treatment_time is provided, the temperature. + Consult the docstring of heat_treatment_time. + + + + + Magnitude of the standard deviation of the heat_treatment_temperature. + + If heat_treatment_time is provided, the magnitude of the standard derivation of the + temperature. Consult the docstring of heat_treatment_time. + + + + + If heat_treatment_time is absent, the rate of the last quenching step. + + Knowledge about this value can give an idea how the sample was heat treated. + However, there are many situations where one can imagine that the scalar value + for just the quenching rate is insufficient. + + If heat_treatment_time is provided, the first derivative of the time-temperature curve. + Consult the docstring of heat_treatment_time for further details. + + + + + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + + If heat_treatment_time is provided, the magnitude of the standard deviation of + the first derivative of the time-temperature curve. + Consult the docstring of heat_treatment_time for further details. + + + + + + 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. + + + + + + + + + + + + Description of the specimen that was cut off from the sample. + + In atom probe jargon this is typically referred to as the tip. + + + + + False, if the specimen is a real one. + True, if the specimen is a virtual one. + + + + + Given name or an alias. Better use identifierNAME and identifier_parent instead. + + A single NXentry should be used only for the characterization of a single specimen. + + + + + Identifier of the sample from which the specimen was cut or the string "n/a". + + The purpose of this field is to support functionalities for tracking sample + provenance via a research data management system. + + + + + 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. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by identifier_parent. + + 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. + + + + + List of comma-separated elements from the IUPAC periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by identifier_parent or walk through + eventually deeply nested groups in data instances. + + + + + Discouraged free-text field. + + + + + True, if the specimen contains a grain or phase boundary. + False, if the specimen is a single crystal. + + + + + True, if the specimen is amorphous. + False, if the specimen is not. + + + + + Ideally measured otherwise best elaborated guess of the initial radius of the + specimen. + + + + + Ideally measured, otherwise best estimate, of the initial 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 smallest angle + between the specimen space z-axis and a vector on the lateral surface + of the cone. + + + + + + The conventions used when reporting crystal orientations. + We follow the best practices of the Material Science community + that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin. + This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + + How are Euler angles interpreted given that there are several choices e.g. zxz, xyz + according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from Tait-Bryan angles. + + + + + + + + + + + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + Which sign convention is followed when converting orientations + between different parametrizations/representations according + to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + + + A coordinate system. Multiple instances require unique names. + + Several Euclidean coordinate systems (CS) are used in the field of atom probe: + + * 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. + Suggested name of the group ``laboratory_reference_frame``. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + Suggested name of the group ``specimen_reference_frame``. + * 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. + Suggested name of the group ``detector_reference_frame``. + * 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. + Suggested name of the group ``reconstruction_reference_frame``. + + To achieve unique names, the prefix "NAMED" should be replaced to + with something derived from an alias for the coordinate system, + or the value of the "alias" field. + + Use the suffix _reference_frame when creating specific instances + of NXcoordinate_system e.g. laboratory_reference_frame, + reconstruction_reference_frame and so on and so forth. + + 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 identifier interval. Typically, the set of + ion evaporation sequence identifiers 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. + + To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A region-of-interest analyzed either during or after the session for which + specific processed data of the measured or simulated data are available. + + If a single instance is required the group should be named atom_probe. + If multiple groups are required these should be named atom_probe1, atom_probe2, + and so on and so forth. + + + + SEM or TEM image of the initial specimen taken before the measurement. + + + + + + + + + + + + + + + + + + + + + + + SEM or TEM image of the final specimen taken after completion of the + measurement. + + + + + + + + + + + + + + + + + + + + + + + Document the control software that was used on the instrument with which raw data + were collected. + + For almost all atom probe instruments, the recorded raw data and metadata follow + proprietary semantics. Therefore, this group can currently often not be filled with + more than the control software and some pointing to digital artifacts (e.g. proprietary files) + that have been collected during the measurement in an effort to document as best as + possible all steps of an analysis workflow. + + The physical quantities measured in an atom probe experiment are time-of-flight and + tuples of arrival_time_pairs as a function of the event chain on the pulser. + From these tuples, hits are computed in a process called hit_finding. + + + + + The control software that was used for running the measurement. + + At least the main software should be reported. If this is the only program + to report name the group "program" and use its below fields program and + version to detail the version used. E.g. program AP Suite, version 6.3 + + It is recommended to report multiple programs though, i.e. also the libraries + and dependencies of the software. In the case of AP Suite/IVAS this can be used + to document the AP Suite GUI, LAS, CamecaRoot, and CernRoot versions. + In this case always name the program groups program1, program2, ... + with program one being AP Suite/IVAS. + + In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's + M-TAP instruments, also use program1, program2, ... with program1 representing + the control software e.g. `M. Monajem and P. Felfer pyCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_. + Further instances (program2, ...) can be used to list the dependencies, the + python virtual environment. + + + + + + + + Possibility to point to files that contain raw data. + + Exemplar files that could be pointed to here when working with + AMETEK/Cameca instruments are the proprietary STR, RRAW, or HITS + files that AP Suite/IVAS generates. + + + + + + + + + The number of delay-line-detector (DLD) wires present. + + + + + + + + + + Alias tuple, typical for the begin and the end of each DLD wire + of the detector. Order follows arrival_time_pairs. + + The order of the first dimension should match that of the + second dimension of the arrival_time_pairs field. + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + + The configuration of a hit finding algorithm and its output. + + Hit finding is the process of deciding which detector signals are significant + and assigning specific ions colliding with the detector + to each observed event. + + + + + + + + + + + + + + + + Evaluated ion impact coordinates on the detector. + Use the depends_on field to specify which reference + frame the positions are defined in. + + + + + + + + Contains the path to an instance of NX_coordinate_system + in which the positions are defined. + + + + + + Number of events of type "golden" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventGolden + field of a CamecaRoot RHIT/HITS file. + + + + + Number of events of type "incomplete" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventIncomplete + field of a CamecaRoot RHIT/HITS file. + + + + + Number of events of type "multiple" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventMultiple + field of a CamecaRoot RHIT/HITS file. + + + + + Number of events of type "partials" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventPartials + field of a CamecaRoot RHIT/HITS file. + + + + + Number of events when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventRecords + field of a CamecaRoot RHIT/HITS file. + + + + + Hit quality is an integer that specifies which category/type a hit was assigned to. + This field lists the human-readable, possibly though proprietary types distinguished. + The indices of this array are used in hit_quality to encode hit_quality for each + pulse in a more efficient way than by repeating the string that is used for each + type as it is provided in this field. + + As an example, assume two types, "golden" and "partial", are distinguished. + If hit_quality_type stores the array "golden", "partial", the index 0 + in hit_quality identifies all those pulses of category "golden", + while the index 1 in hit_quality identifies all of category "partial". + + + + + + + + Hit quality identifier for each pulse. + Identifier has to be within hit_quality_type. + + + + + + + + The number of ions determined to have been collected on the same pulse. + These ions may hit different pixels, or even the same detector pixel. + The hit_multiplicity is not related to the makeup of the ions and should not be + confused with the number of atoms or elements that constitute a molecular ion. + + + + + + + + + + + + + + + + + + + + + + Integer which defines the first evaporation_id. + Typically, this is either zero or one. + + + + + There are two possibilities to report evaporation_id values: + + If evaporation_id_offset is provided, the evaporation_id values are defined + by the sequence :math:`[evaporation\_id\_offset, evaporation\_id\_offset + n]` + with :math:`n` the number of ions in the reconstructed volume. + + Alternatively, evaporation_id_offset is not provided but instead a + a sequence of :math:`n` values is defined, these integer values + do not need to be sorted. + + + + + + + + + + + + + + + Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. + + The voltage-and-bowl correction is a data post-processing step to correct ion impact + positions for flight path differences, detector bias, and nonlinearities. + + + + + + + + + + + + + + + + + Reference mass-to-charge state ratio value + + For example 16 Da as mentioned by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). + + + + + + Raw time-of-flight data without corrections. + + + + + + + + The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate + + + + + Calibrated time-of-flight. + + + + + + + + + + + + + + + + + + + + + + + Mass calibration with unit peaks/interp. as mentioned by `T. Blum et al. + <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). + + + + + Inverse of the mass resolution :math:`\frac{M}{\Delta M}` as mentioned by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). + + Multiple values can be reported but reporting each is only useful when stating also: + + * The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. + Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). + Consequently, mass_resolution_fw should needs to be a vector of the same length + and using the same order like used for mass_resolution, i.e. the first mass resolution was + defined at the maximum as defined by the first value from mass_resolution_fw. + * The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` + As many instances of mass_resolutionION should be used with instances + numbered starting from 1 up to the length of the mass_resolution vector. + + + + + + + + The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. + Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). + Consequently, mass_resolution_fw should needs to be a vector of the same length + and using the same order like used for mass_resolution, i.e. the first mass resolution was + defined at the maximum as defined by the first value from mass_resolution_fw. + + + + + + + + The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` + As many instances of mass_resolutionION should be used with instances + numbered starting from 1 up to the length of the mass_resolution vector. + + + + + + + + + + + + + + + + + + + + + For LEAP and APSuite/IVAS-based analyses the root file which stores + the settings whereby an RHIT/HITS file can be used to regenerate the + reconstructed volume that is here referred to. + + The respective RHIT/HITS file should ideally be specified in the serialized + group of the hit_finding section of this application definition. + + + + + + + + + For LEAP and APSuite/IVAS-based analyses the resulting typically + file with the reconstructed positions and calibrated mass-to-charge- + state ratio values. + + For other data collection/analysis software the data artifact which comes + closest conceptually to AMETEK/Cameca's typical file formats. + + These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, + which should be stored alongside this record in the research data + management system. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The respective ranging definitions file RNG/RRNG/ENV/HDF5. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + (Out-of-sync, time-independent) background levels in ppm/ns + reported by e.g. APSuite/IVAS for LEAP systems. + + + + + The mass-resolving power (MRP) value + + `D. Larson et al. <https://doi.org/10.1007/978-1-4614-8721-0>`_ report Eq. D.8 in page 282: + + :math:`MRP = \frac{1}{2\delta t} \cdot \sqrt{\frac{m}{n}\frac{1}{2eV}L}`, + + with :math:`\delta t` representing the timing imprecision, :math:`\frac{m}{n}` the mass-to-charge state ratio, + :math:`e` the elementary charge, :math:`V` the potential difference, and :math:`L` the flight path length. + + Timing imprecision is caused by variations of flight path length and voltage, + the fact that the precision of electronics is finite and a spread of the + time-of-departure of individual ions is observed. + + + + + Mass-to-charge state ratio :math:`\frac{m}{n}` at which mrp_value was specified. + + + + + Potential difference :math:`V` at which mrp_value was specified. + + + + + Flight path length :math:`L` at which mrp_value was specified. + + + + + + + + + + + + + + + + Category for the peak offering a qualitative statement of the location of the peak + in light of limited mass-resolving power that is relevant for + composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ + for examples of each category: + + * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` + * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` + * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states + * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` + * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` + * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` + + + + + + + + + + + + + + + + + + + + + + + + + + Ions that were ranged. + + The value zero is reserved for documenting that an ion was unranged. + Identifier for ranged ions need to start at 1 up to number_of_ion_types. + + + + + + + + + + + + + + + + + + + + + + + + The iontype identifier for each ion that was best matching; + stored in the order of the evaporation_id. + + The value zero is reserved for documenting that an ion was unranged. + Identifier for ranged ions need to start at 1 up to number_of_ion_types. + + + + + + + + + + diff --git a/applications/nyaml/NXapm.yaml b/applications/nyaml/NXapm.yaml new file mode 100644 index 0000000000..5372f6bf3f --- /dev/null +++ b/applications/nyaml/NXapm.yaml @@ -0,0 +1,3131 @@ +category: application +doc: | + Application definition for real or simulated atom probe and field-ion microscopy experiments. + + Atom probe tomography and field-ion microscopy are methods for characterizing materials + through induced controlled extraction of individual atoms as ions and molecular ions from + a sharp needle-shaped specimen. + + Offering isotopic and nanometer-scale resolution, atom probe data enable quantification of + local chemical composition and computing of volumetric reconstructions which are models for + the atomic architecture of the small specimen volume analyzed. These reconstructions provide + input for characterization of atomic segregation at crystal defects. The term microstructural features + is considered as a narrow synonym for crystal defects. + + The aim of the NXapm application definition is to provide a general yet specific enough + solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments. + + Before summarizing the design of the base classes and the parts of the NXapm application definition, + it is worthwhile to recall and distinguish concepts that are related to atom extraction + events and the molecular ions that are frequently generated by the sequence of events: + + * An atom probe instrument uses laser or voltage pulsing events to trigger ion extraction events. + * These ions are accelerated in an electric field towards a position-sensitive detector system. + Physical events and corresponding signal on this detector is triggered by an ion hitting the detector. + Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. + * Note that only a part the specimen volume can be measured and finite detection efficiency means that + not all atoms in the measured volume will be detected. Neutral atoms can escape detection. Some ions + escape detection because they hit into walls of the analysis_chamber. + + Raw data are typically processed as follows: + + * Detector pulses and their timing are processed and discriminated into signal events of different quality levels. + High quality events might be considered in further processing to identify the corresponding molecular ion + and its original position in the reconstructed volume. + * Signal calibration and filtering steps are applied to convert raw time-of-flight data to calibrated + mass-to-charge state ratio values and obtain calibrated impact positions on the detector. + * Ranging and identifying an ion that corresponds to each detector event. + Isotopic abundance and theoretical models inform these ranging algorithms. + * Finally, such selected ion impact positions and iontypes are used to compute a reconstructed volume of + the specimen using backprojection algorithms. In effect, an atom probe measurement is a combination of + a data acquisition and a data analysis workflow. + + Not only in AMETEK/Cameca's APSuite/IVAS software, which the majority of atom probers use, these concepts + are well distinguished. However, the algorithms used to transform correlations between pulses and physical + events into actual events, the so-called detector hits of ions, is a proprietary one. This algorithm is also + referred to as the hit finding algorithm. + + Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting + schema where the course of the specimen evaporation is documented such that quantities are a function of + evaporation_id i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. + That is the evaporation_id values take the role of an implicit time and course of the experiment given that + ion extraction physically is a sequential process. + + This application definition includes fields that the atom probe community has decided to represent best practices + for reporting atom probe measurements. Exemplar mapping tables are provided for documents that reported these + best practices to translate technical term into concepts of the NXapm application definition. + + *The NeXus application definition NXapm defines a hierarchical data model with ten building blocks:* + + The data model represents a tree of concepts. The tree is constructed from groups of concepts representing + the branches, together with fields and attributes representing leaves. NXapm is defined by composing and + specializing base classes into the following ten categories: + + - The field ``definition`` specifies that the data schema is NXapm. In combination with + administrative metadata such as the attribute ``NeXus_version`` provided by :ref:`NXroot` this + specifies which version of NXapm the instance data in a NeXus/HDF5 file are compliant with. + - The fields ``run_number``, ``experiment_alias``, ``experiment_description`` and + the group ``userID`` provide concepts for storing organizational metadata that + contextualize the work within the research workflow and humans involved in this. + - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. + - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations or notes + that are associated with the data, i.e. other artifacts that are deemed relevant when reporting about + a measurement or simulation. These groups are useful when NXapm is used as a serialization format for + technology-partner-agnostic archival of data and metadata that have been collected during a session with + an atom probe instrument. The terms run and session are understood as exact synonyms that refer to an + uninterrupted period of measurement. Resuming measurement on a specimen after an interruption is viewed + as a new run and the new data should not be appended to the previous run, but written to either a new NXentry, + or a new file. Removing the specimen from the instrument is an interruption. Changing evaporation conditions + while the specimen is remains in the analysis_chamber and resuming thereafter the measurement + is not considered as an interruption. It is a common strategy to probe the evaporation process for different + instrument parameters. Each individual collection should then though be stored in an own NXevent_data_apm + group. Parking the specimen to the buffer_chamber and resuming the measurement at a later stage is an interruption. + During a run, the microscope is used for a certain amount of time to characterize a single specimen. + - The groups ``sample`` and ``specimen`` provide concepts for storing metadata about the sample and the specimen, + i.e. the smaller part that was removed from the sample to be measured in the atom probe session. + The term "tip" in the context of atom probe research is considered jargon. + Specimen is an exact synonym for tip. + - The field ``operation_mode`` and group ``measurement`` provides concepts that + are useful for describing a measurement during a session with an atom probe or field-ion microscope. + This includes the chain of events of data and metadata that were collected during such a session. + - The group ``simulation`` provides concepts that are useful for describing a simulation of an + atom extraction, ionization, and ion trajectory simulation. Combined with ``measurement`` + this provides a data schema for defining a digital twin of the instrument and its setup. + - The groups ``consistent_rotations``, and ``NAMED_reference_frame`` provide concepts for + reporting coordinate systems (frames of reference) and rotation conventions that clarify how data + should be interpreted specifying the rotation of orientable objects in the microscope, its components, + or of crystals and crystal defects in the material analyzed. + - The group ``atom_probeID`` provides concepts for the computational workflows that were + used to convert raw detector data into reconstructed ion positions and documentation of + ranging definitions made. + - The group ``profiling`` provides concepts for reporting computational details such as + programs and libraries used, for documenting the libraries of virtual environments such as those used + by conda or python virtual environment, including details about the computing hardware used, and + documenting capabilities for performance analyses and benchmarking of the software or its parts. + + *Design choices:* + + Given that most atom probe instruments across the globe were built by AMETEK/Cameca and are delivered + with the AP Suite/IVAS software there is some homogeneity in how a measurement is performed and which data + artifacts and algorithms used for data processing. Complementary use of open-source software specifically for + the reconstruction, ranging, and later data processing stages contributes to a landscape of multiple tools in use. + Therefore, communication of atom probe research differs between user groups. This holds even more so true + for the sub community in atom probe which study physical mechanisms involved during ionization to the point that + here that almost each research work defines different simulation tools with different types of data artifacts. + + NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to + offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended + but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex + use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the + optional group ``measurement`` with its required child ``measurement/instrument``: + Users which report simulations are not forced to document the instrument but users which have characterized + a specimen are motivated to report about the instrument. They are though not necessarily required to report all + the details of the instruments' components because the design pattern is applied recursively. + + *NXapm distinguishes and stores instance data based on how long they remain unchanged:* + + ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. + The first group is designed for storing metadata about the instrument that do not change over the course of the session. + Examples are the name of the technology partner who built the microscope or whether a laser or voltage pulser + and reflectron exists or not. The second group is designed for metadata and data that are collected during + the session with the instrument. These, are stored as instances of ``measurement/eventID``, + events that can be time-stamped individually. + Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose is to + store those specific state and settings of the instrument that was present during the collection of the event. + Thereby, changing conditions such as compaigns with different target detection rate can be stored. + + Noteworthy, such an approach of the atom probe detecting groups of events and storing these as groups has also + been in use in the proprietary software via CamecaRoot, a set of customized data structures and file formats that use + the CernRoot library. By virtue of design this reduces unnecessary repetition of metadata stored in the first group. + + ``atom_probeID`` offer classes for the each task relevant task in the data processing pipeline that converts raw detector + event data to calibrated mass-to-charge-state-ratio values and hit_position on the detector. These include + ``initial_specimen``, and ``final_specimen`` locations for storing images of the specimen prior/after the measurement as + considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the + hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about + to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations + and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the + conversion from time-of-flight to mass-to-charge-state-ratio values. + + Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how + from all the previous sources of input one can compute a reconstructed volume, and apply peak fitting routines on the + mass-to-charge-state-ratio histogram to label ions, i.e. range them for their isotopic identity. + Group ``atom_probeID/reconstruction/naive_discretization`` offers a standardized way to report simple + three-dimensional histograms. Group ``atom_probeID/ranging/peak_identification/ionID`` and its + complementing group ``atom_probeID/ranging/peak_identification/ionID/charge_state_analysis`` + solves the issue that the ranging definitions in classical file formats are not reported for always for their isotopic identity + and charge state. The field ``atom_probeID/ranging/peak_identification/iontypes`` provides a place for + storing a compact representation of the results of each ranging definition made at the level of each ion. + + *The compatibility of NXapm and NXem:** + + The design of NXapm mirrors that of :ref:`NXem`. This was an intentional choice to support the increasingly stronger connection between + these two materials characterization methods, especially in light of recent advances in the direct coupling of atom probe and + transmission electron microscopes and scanning transmission electron microscopes. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ht: | + Number of hit qualities, the so-called hit types, distinguished. + n_dld: | + Number of delay-line-detector (DLD) wires of the detector. + n_bins: | + Number of bins used in the mass-to-charge-state-ratio spectrum. + p: | + Number of pulses collected in between start_time and end_time resolved by an + instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of + ions included in the reconstructed volume if the application definition is used + to store results of an already reconstructed dataset. + p_out: | + Number of pulses returned by the hit_finding algorithm. + Neither necessarily equal to p nor to n. + n: | + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process, the so-called + evaporation_id. This identifier must not be confused with the pulse_id. + This value is typically smaller than both p and p_out. + m_r: | + Number of mass resolution values. +type: group +NXapm(NXobject): + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] + definition(NX_CHAR): + \@version(NX_CHAR): + exists: optional + enumeration: [NXapm] + profiling(NXcs_profiling): + exists: optional + doc: | + The configuration of the software that was used to generate this NeXus file. + programID(NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + program(NX_CHAR): + \@version(NX_CHAR): + environment(NXcollection): + exists: recommended + doc: | + Programs and libraries representing the computational environment + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program(NX_CHAR): + \@version(NX_CHAR): + run_number(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + The identifier whereby the experiment is referred to in the control software. + + It is common practice in atom probe research to refer to a measurement on a single + specimen as a run. When working with AMETEK/Cameca instruments it is a common + practice also to store all data associated with such a run in files whose name + is composed from a prefix that details the type of instrument (e.g. R5076) followed + by the run_number. These filenames are often used as the specimen_name or + experiment_identifier. The terms run and session are understood as exact synonyms. + + For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, + or the instruments at GPM in Rouen, use the identifier which matches + best conceptually 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; provided these + RHIT or HITS files respectively are stored alongside a data artifact. + With NXapm the RHIT or HITS can be stored via NXnote in the + hit_finding algorithm section. + + 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. Such interrupted runs + should be stored as individual :ref:`NXentry` instances in one NeXus file. + experiment_alias(NX_CHAR): + exists: optional + doc: | + Alias or short name which scientists can use to refer to this experiment. + experiment_description(NX_CHAR): + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into the field. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the atom probe session started. If the exact duration of + the measurement is not relevant, start_time only should be used. + + The start_time is required in order to ensure that at least one point in time + is provided for full temporal context to a measurement and simulation + when writing instance data using NXapm. Otherwise, the instance data + can not be sorted in order or even placed in a logical sequence to other + steps of the research workflow, which would disallow using functionalities + in research data management systems that rely on temporal context. + + Specifying start_time and end_time is useful for capturing more detailed + bookkeeping 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. For this + purpose the :ref:`NXevent_data_apm` instance should be used. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the atom probe session ended. + + Writing the end_time can be a tricky in practice. If written at the start + of the experiment, it can only be an estimate. If written at the end, there + is the risk for having the computer crash or lose power. The absence of + end_time should not be interpreted as that the experiment was aborted. + Only, the field ``status`` should be used for communicating such abortion. + elapsed_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + doc: | + How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime + citeID(NXcite): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doi(NX_CHAR): + noteID(NXnote): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + operation_mode(NX_CHAR): + doc: | + What type of atom probe experiment is performed to inform research data management + systems and allow filtering: + + * apt are experiments where the analysis_chamber has no imaging gas. + Experiments with LEAP instruments are typically with this operation_mode. + * 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. + Few experiments of this type have been performed, as it can be detrimental + to LEAP systems (see `S. Katnagallu et al. `_). + enumeration: + open_enum: true + items: [apt, fim, apt_fim] + userID(NXuser): + exists: recommended + nameType: partial + identifierNAME(NX_CHAR): + nameType: partial + exists: recommended + \@type(NX_CHAR): + name(NX_CHAR): + exists: optional + 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. + + In NXapm, a measurement is performed on a specimen. Since APM specimens + are very small, they are typically cut from a larger object with some + scientific significance, which NXapm refers to as a sample. + identifierNAME(NX_CHAR): + nameType: partial + exists: recommended + is_simulation(NX_BOOLEAN): + doc: | + False, if the sample is a real one. + True, if the sample is a virtual one. + alias(NX_CHAR): + doc: | + Given name/alias for the sample. + grain_diameter(NX_FLOAT): + exists: optional + unit: NX_LENGTH + 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. + + If the specimen does not contain many crystals average values + might be an unreliable descriptor. + + Reporting a grain size may be useful though as it allows + judging if specific features are expected to be found in the + detector hit map. + grain_diameter_errors(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Magnitude of the standard deviation of the grain_diameter. + heat_treatment_time(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + An array of elapsed time, the independent axis, of a time-temperature curve. + + This field can be used in combination with heat_treatment_temperature and + heat_treatment_temperature_errors as well as heat_treatment_quenching_rate + and heat_treatment_quenching_rate_errors respectively. In this case, these fields + should also be stored as an array with the same dimensions as heat_treatment_time + to store the dependant axes of a time-temperature curve as well as its first derivative. + heat_treatment_temperature(NX_FLOAT): + exists: optional + unit: NX_TEMPERATURE + doc: | + If heat_treatment_time is absent, 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 a documentation of the annealing + treatment as a function of time is available one should better + rely on this information and have it stored alongside the NeXus file. + + If heat_treatment_time is provided, the temperature. + Consult the docstring of heat_treatment_time. + heat_treatment_temperature_errors(NX_FLOAT): + exists: optional + unit: NX_TEMPERATURE + doc: | + Magnitude of the standard deviation of the heat_treatment_temperature. + + If heat_treatment_time is provided, the magnitude of the standard derivation of the + temperature. Consult the docstring of heat_treatment_time. + heat_treatment_quenching_rate(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + If heat_treatment_time is absent, the rate of the last quenching step. + + Knowledge about this value can give an idea how the sample was heat treated. + However, there are many situations where one can imagine that the scalar value + for just the quenching rate is insufficient. + + If heat_treatment_time is provided, the first derivative of the time-temperature curve. + Consult the docstring of heat_treatment_time for further details. + heat_treatment_quenching_rate_errors(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + + If heat_treatment_time is provided, the magnitude of the standard deviation of + the first derivative of the time-temperature curve. + Consult the docstring of heat_treatment_time for further details. + description(NX_CHAR): + exists: optional + chemical_composition(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(NX_CHAR): + ELEMENT(NXatom): + exists: ['min', '1', 'max', '118'] + nameType: any + chemical_symbol(NX_CHAR): + composition(NX_FLOAT): + composition_errors(NX_FLOAT): + exists: recommended + specimen(NXsample): + doc: | + Description of the specimen that was cut off from the sample. + + In atom probe jargon this is typically referred to as the tip. + identifierNAME(NX_CHAR): + nameType: partial + exists: recommended + is_simulation(NX_BOOLEAN): + doc: | + False, if the specimen is a real one. + True, if the specimen is a virtual one. + alias(NX_CHAR): + exists: recommended + doc: | + Given name or an alias. Better use identifierNAME and identifier_parent instead. + + A single NXentry should be used only for the characterization of a single specimen. + identifier_parent(NX_CHAR): + exists: recommended + doc: | + Identifier of the sample from which the specimen was cut or the string "n/a". + + The purpose of this field is to support functionalities for tracking sample + provenance via a research data management system. + 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. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by identifier_parent. + + 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. + atom_types(NX_CHAR): + doc: | + List of comma-separated elements from the IUPAC periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by identifier_parent or walk through + eventually deeply nested groups in data instances. + description(NX_CHAR): + exists: optional + doc: | + Discouraged free-text field. + is_polycrystalline(NX_BOOLEAN): + exists: recommended + doc: | + True, if the specimen contains a grain or phase boundary. + False, if the specimen is a single crystal. + is_amorphous(NX_BOOLEAN): + exists: recommended + doc: | + True, if the specimen is amorphous. + False, if the specimen is not. + initial_radius(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + Ideally measured otherwise best elaborated guess of the initial radius of the + specimen. + shank_angle(NX_FLOAT): + exists: recommended + unit: NX_ANGLE + doc: | + Ideally measured, otherwise best estimate, of the initial 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 smallest angle + between the specimen space z-axis and a vector on the lateral surface + of the cone. + consistent_rotations(NXparameters): + exists: recommended + doc: | + The conventions used when reporting crystal orientations. + We follow the best practices of the Material Science community + that are defined in reference ``_. + rotation_handedness(NX_CHAR): + doc: | + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin. + This is in accordance with convention 2 of reference ``_. + + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation according to convention 3 + of reference ``_. + enumeration: [passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several choices e.g. zxz, xyz + according to convention 4 of reference ``_. + + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from Tait-Bryan angles. + enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of reference ``_. + enumeration: [rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parametrizations/representations according + to convention 6 of reference ``_. + enumeration: [p_plus_one, p_minus_one] + NAMED_reference_frame(NXcoordinate_system): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + doc: | + A coordinate system. Multiple instances require unique names. + + Several Euclidean coordinate systems (CS) are used in the field of atom probe: + + * 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. + Suggested name of the group ``laboratory_reference_frame``. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + Suggested name of the group ``specimen_reference_frame``. + * 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. + Suggested name of the group ``detector_reference_frame``. + * 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. + Suggested name of the group ``reconstruction_reference_frame``. + + To achieve unique names, the prefix "NAMED" should be replaced to + with something derived from an alias for the coordinate system, + or the value of the "alias" field. + + Use the suffix _reference_frame when creating specific instances + of NXcoordinate_system e.g. laboratory_reference_frame, + reconstruction_reference_frame and so on and so forth. + + 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 identifier interval. Typically, the set of + ion evaporation sequence identifiers 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. + + To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + exists: recommended + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + measurement(NXapm_measurement): + exists: optional + status(NX_CHAR): + exists: recommended + quality(NX_CHAR): + exists: recommended + instrument(NXinstrument_apm): + type(NX_CHAR): + exists: recommended + location(NX_CHAR): + exists: recommended + flight_path(NX_FLOAT): + exists: recommended + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + reflectron(NXcomponent): + exists: optional + applied(NX_BOOLEAN): + local_electrode(NXlens_em): + exists: recommended + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + aperture_type(NX_CHAR): + exists: recommended + ion_detector(NXdetector): + exists: recommended + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + pulser(NXcomponent): + exists: recommended + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + sourceID(NXsource): + exists: ['min', '0', 'max', '2'] + nameType: partial + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + stage(NXmanipulator): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + analysis_chamber(NXcomponent): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + buffer_chamber(NXcomponent): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + load_lock_chamber(NXcomponent): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + getter_pump(NXpump): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + roughening_pump(NXpump): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + turbomolecular_pump(NXpump): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + eventID(NXevent_data_apm): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + instrument(NXinstrument_apm): + exists: recommended + reflectron(NXcomponent): + exists: recommended + voltage(NX_FLOAT): + local_electrode(NXlens_em): + exists: recommended + voltage(NX_FLOAT): + pulser(NXcomponent): + exists: recommended + pulse_mode(NX_CHAR): + pulse_frequency(NX_FLOAT): + pulse_fraction(NX_FLOAT): + pulse_voltage(NX_FLOAT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + pulse_number(NX_UINT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + standing_voltage(NX_FLOAT): + exists: optional + dimensions: + rank: 1 + dim: (n,) + sourceID(NXsource): + exists: ['min', '0', 'max', '2'] + nameType: partial + wavelength(NX_FLOAT): + exists: recommended + unit: NX_WAVELENGTH + power(NX_FLOAT): + unit: NX_POWER + pulse_energy(NX_FLOAT): + dimensions: + rank: 1 + dim: (n,) + stage(NXmanipulator): + temperature_sensor(NXsensor): + measurement(NX_CHAR): + value(NX_FLOAT): + analysis_chamber(NXcomponent): + pressure_sensor(NXsensor): + measurement(NX_CHAR): + value(NX_FLOAT): + control(NXparameters): + exists: recommended + evaporation_control(NX_CHAR): + target_detection_rate(NX_NUMBER): + simulation(NXapm_simulation): + exists: optional + atom_probeID(NXroi_process): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doc: | + A region-of-interest analyzed either during or after the session for which + specific processed data of the measured or simulated data are available. + + If a single instance is required the group should be named atom_probe. + If multiple groups are required these should be named atom_probe1, atom_probe2, + and so on and so forth. + initial_specimen(NXimage): + exists: recommended + doc: | + SEM or TEM image of the initial specimen taken before the measurement. + image_2d(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + real(NX_NUMBER): + axis_j(NX_NUMBER): + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + final_specimen(NXimage): + exists: recommended + doc: | + SEM or TEM image of the final specimen taken after completion of the + measurement. + image_2d(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + real(NX_NUMBER): + axis_j(NX_NUMBER): + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + raw_data(NXprocess): + exists: optional + doc: | + Document the control software that was used on the instrument with which raw data + were collected. + + For almost all atom probe instruments, the recorded raw data and metadata follow + proprietary semantics. Therefore, this group can currently often not be filled with + more than the control software and some pointing to digital artifacts (e.g. proprietary files) + that have been collected during the measurement in an effort to document as best as + possible all steps of an analysis workflow. + + The physical quantities measured in an atom probe experiment are time-of-flight and + tuples of arrival_time_pairs as a function of the event chain on the pulser. + From these tuples, hits are computed in a process called hit_finding. + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doc: | + The control software that was used for running the measurement. + + At least the main software should be reported. If this is the only program + to report name the group "program" and use its below fields program and + version to detail the version used. E.g. program AP Suite, version 6.3 + + It is recommended to report multiple programs though, i.e. also the libraries + and dependencies of the software. In the case of AP Suite/IVAS this can be used + to document the AP Suite GUI, LAS, CamecaRoot, and CernRoot versions. + In this case always name the program groups program1, program2, ... + with program one being AP Suite/IVAS. + + In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's + M-TAP instruments, also use program1, program2, ... with program1 representing + the control software e.g. `M. Monajem and P. Felfer pyCCAPT `_. + Further instances (program2, ...) can be used to list the dependencies, the + python virtual environment. + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: recommended + doc: | + Possibility to point to files that contain raw data. + + Exemplar files that could be pointed to here when working with + AMETEK/Cameca instruments are the proprietary STR, RRAW, or HITS + files that AP Suite/IVAS generates. + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + number_of_dld_wires(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + The number of delay-line-detector (DLD) wires present. + enumeration: [1, 2, 3] + dld_wire_names(NX_CHAR): + exists: optional + doc: | + Alias tuple, typical for the begin and the end of each DLD wire + of the detector. Order follows arrival_time_pairs. + + The order of the first dimension should match that of the + second dimension of the arrival_time_pairs field. + dimensions: + rank: 2 + dim: (n_dld, 2) + arrival_time_pairs(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + dimensions: + rank: 3 + dim: (p, n_dld, 2) + hit_finding(NXprocess): + exists: recommended + doc: | + The configuration of a hit finding algorithm and its output. + + Hit finding is the process of deciding which detector signals are significant + and assigning specific ions colliding with the detector + to each observed event. + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + config(NXnote): + exists: recommended + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + hit_positions(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Evaluated ion impact coordinates on the detector. + Use the depends_on field to specify which reference + frame the positions are defined in. + dimensions: + rank: 2 + dim: (p_out, 2) + \@depends_on(NX_CHAR): + doc: | + Contains the path to an instance of NX_coordinate_system + in which the positions are defined. + total_event_golden(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of events of type "golden" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventGolden + field of a CamecaRoot RHIT/HITS file. + total_event_incomplete(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of events of type "incomplete" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventIncomplete + field of a CamecaRoot RHIT/HITS file. + total_event_multiple(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of events of type "multiple" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventMultiple + field of a CamecaRoot RHIT/HITS file. + total_event_partials(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of events of type "partials" when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventPartials + field of a CamecaRoot RHIT/HITS file. + total_event_record(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of events when APSuite/IVAS was used as the + software with which the measurement was performed. + + The value can be extracted from the CRunHeader.fTotalEventRecords + field of a CamecaRoot RHIT/HITS file. + hit_quality_type(NX_CHAR): + exists: optional + doc: | + Hit quality is an integer that specifies which category/type a hit was assigned to. + This field lists the human-readable, possibly though proprietary types distinguished. + The indices of this array are used in hit_quality to encode hit_quality for each + pulse in a more efficient way than by repeating the string that is used for each + type as it is provided in this field. + + As an example, assume two types, "golden" and "partial", are distinguished. + If hit_quality_type stores the array "golden", "partial", the index 0 + in hit_quality identifies all those pulses of category "golden", + while the index 1 in hit_quality identifies all of category "partial". + dimensions: + rank: 1 + dim: (n_ht,) + hit_quality(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Hit quality identifier for each pulse. + Identifier has to be within hit_quality_type. + dimensions: + rank: 1 + dim: (p_out,) + hit_multiplicity(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of ions determined to have been collected on the same pulse. + These ions may hit different pixels, or even the same detector pixel. + The hit_multiplicity is not related to the makeup of the ions and should not be + confused with the number of atoms or elements that constitute a molecular ion. + dimensions: + rank: 1 + dim: (p_out,) + hit_spatial_filtering(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: optional + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + evaporation_id_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which defines the first evaporation_id. + Typically, this is either zero or one. + evaporation_id(NX_INT): + unit: NX_UNITLESS + doc: | + There are two possibilities to report evaporation_id values: + + If evaporation_id_offset is provided, the evaporation_id values are defined + by the sequence :math:`[evaporation\_id\_offset, evaporation\_id\_offset + n]` + with :math:`n` the number of ions in the reconstructed volume. + + Alternatively, evaporation_id_offset is not provided but instead a + a sequence of :math:`n` values is defined, these integer values + do not need to be sorted. + dimensions: + rank: 1 + dim: (n,) + hit_filter(NXcs_filter_boolean_mask): + exists: recommended + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + + # at this point the set of events p_out has been filtered down to n + voltage_and_bowl(NXprocess): + exists: recommended + doc: | + Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. + + The voltage-and-bowl correction is a data post-processing step to correct ion impact + positions for flight path differences, detector bias, and nonlinearities. + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: optional + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + config(NXparameters): + correction_peak(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + Reference mass-to-charge state ratio value + + For example 16 Da as mentioned by `T. Blum et al. `_ (page 371). + raw_tof(NX_FLOAT): + exists: recommended + doc: | + Raw time-of-flight data without corrections. + dimensions: + rank: 1 + dim: (n,) + tof_zero_estimate(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate + calibrated_tof(NX_FLOAT): + exists: recommended + doc: | + Calibrated time-of-flight. + dimensions: + rank: 1 + dim: (n,) + mass_to_charge_conversion(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: recommended + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + config(NXparameters): + mass_calibration(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + Mass calibration with unit peaks/interp. as mentioned by `T. Blum et al. + `_ (page 371). + mass_resolution(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + Inverse of the mass resolution :math:`\frac{M}{\Delta M}` as mentioned by `T. Blum et al. `_ (page 371). + + Multiple values can be reported but reporting each is only useful when stating also: + + * The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. + Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). + Consequently, mass_resolution_fw should needs to be a vector of the same length + and using the same order like used for mass_resolution, i.e. the first mass resolution was + defined at the maximum as defined by the first value from mass_resolution_fw. + * The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` + As many instances of mass_resolutionION should be used with instances + numbered starting from 1 up to the length of the mass_resolution vector. + dimensions: + rank: 1 + dim: (m_r,) + mass_resolution_fw(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. + Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). + Consequently, mass_resolution_fw should needs to be a vector of the same length + and using the same order like used for mass_resolution, i.e. the first mass resolution was + defined at the maximum as defined by the first value from mass_resolution_fw. + dimensions: + rank: 1 + dim: (m_r,) + mass_resolutionION(NXatom): + nameType: partial + exists: recommended + doc: | + The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` + As many instances of mass_resolutionION should be used with instances + numbered starting from 1 up to the length of the mass_resolution vector. + nuclide_hash(NX_UINT): + exists: recommended + name(NX_CHAR): + mass_to_charge(NX_FLOAT): + dimensions: + rank: 1 + dim: (n,) + reconstruction(NXapm_reconstruction): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: recommended + doc: | + For LEAP and APSuite/IVAS-based analyses the root file which stores + the settings whereby an RHIT/HITS file can be used to regenerate the + reconstructed volume that is here referred to. + + The respective RHIT/HITS file should ideally be specified in the serialized + group of the hit_finding section of this application definition. + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + results(NXnote): + exists: recommended + doc: | + For LEAP and APSuite/IVAS-based analyses the resulting typically + file with the reconstructed positions and calibrated mass-to-charge- + state ratio values. + + For other data collection/analysis software the data artifact which comes + closest conceptually to AMETEK/Cameca's typical file formats. + + These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, + which should be stored alongside this record in the research data + management system. + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + config(NXparameters): + exists: recommended + voltage_filter_initial(NX_FLOAT): + exists: recommended + voltage_filter_final(NX_FLOAT): + exists: recommended + protocol_name(NX_CHAR): + exists: recommended + primary_element(NX_CHAR): + exists: recommended + efficiency(NX_FLOAT): + exists: recommended + flight_path(NX_FLOAT): + exists: recommended + evaporation_field(NX_CHAR): + exists: recommended + image_compression(NX_FLOAT): + exists: recommended + kfactor(NX_FLOAT): + exists: recommended + shank_angle(NX_FLOAT): + exists: recommended + ion_volume(NX_FLOAT): + exists: recommended + crystallographic_calibration(NX_CHAR): + exists: recommended + comment(NX_CHAR): + exists: recommended + reconstructed_positions(NX_FLOAT): + dimensions: + rank: 2 + dim: (n, 3) + naive_discretization(NXprocess): + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + (NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + dimensions: + rank: 3 + dim: (n_z, n_y, n_x) + axis_z(NX_FLOAT): + dimensions: + rank: 1 + dim: (n_z,) + \@long_name(NX_CHAR): + axis_y(NX_FLOAT): + dimensions: + rank: 1 + dim: (n_y,) + \@long_name(NX_CHAR): + axis_x(NX_FLOAT): + dimensions: + rank: 1 + dim: (n_x,) + \@long_name(NX_CHAR): + volume(NX_FLOAT): + exists: recommended + field_of_view(NX_FLOAT): + exists: recommended + ranging(NXapm_ranging): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + source(NXnote): + exists: recommended + doc: | + The respective ranging definitions file RNG/RRNG/ENV/HDF5. + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + mass_to_charge_distribution(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + min_mass_to_charge(NX_FLOAT): + max_mass_to_charge(NX_FLOAT): + n_mass_to_charge(NX_POSINT): + mass_spectrum(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + dimensions: + rank: 1 + dim: (n_bins,) + \@long_name(NX_CHAR): + axis_mass_to_charge(NX_FLOAT): + dimensions: + rank: 1 + dim: (n_bins,) + \@long_name(NX_CHAR): + background_quantification(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + background(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + (Out-of-sync, time-independent) background levels in ppm/ns + reported by e.g. APSuite/IVAS for LEAP systems. + mrp_value(NX_FLOAT): + exists: recommended + unit: NX_DIMENSIONLESS + doc: | + The mass-resolving power (MRP) value + + `D. Larson et al. `_ report Eq. D.8 in page 282: + + :math:`MRP = \frac{1}{2\delta t} \cdot \sqrt{\frac{m}{n}\frac{1}{2eV}L}`, + + with :math:`\delta t` representing the timing imprecision, :math:`\frac{m}{n}` the mass-to-charge state ratio, + :math:`e` the elementary charge, :math:`V` the potential difference, and :math:`L` the flight path length. + + Timing imprecision is caused by variations of flight path length and voltage, + the fact that the precision of electronics is finite and a spread of the + time-of-departure of individual ions is observed. + mrp_mass_to_charge(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + Mass-to-charge state ratio :math:`\frac{m}{n}` at which mrp_value was specified. + mrp_voltage(NX_FLOAT): + exists: recommended + unit: NX_VOLTAGE + doc: | + Potential difference :math:`V` at which mrp_value was specified. + mrp_flight_path_length(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + Flight path length :math:`L` at which mrp_value was specified. + peak_search(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + peakID(NXpeak): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + label(NX_CHAR): + exists: recommended + description(NX_CHAR): + exists: recommended + category(NX_CHAR): + exists: recommended + doc: | + Category for the peak offering a qualitative statement of the location of the peak + in light of limited mass-resolving power that is relevant for + composition quantification. See `D. Larson et al. (p172) `_ + for examples of each category: + + * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` + * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` + * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states + * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` + * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` + * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` + enumeration: [0, 1, 2, 3, 4, 5] + position(NX_NUMBER): + + # peak deconvolution(NXprocess): + peak_identification(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + programID(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + program(NX_CHAR): + \@version(NX_CHAR): + number_of_ion_types(NX_UINT): + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + ionID(NXatom): + nameType: partial + exists: ['min', '1', 'max', '256'] + doc: | + Ions that were ranged. + + The value zero is reserved for documenting that an ion was unranged. + Identifier for ranged ions need to start at 1 up to number_of_ion_types. + nuclide_hash(NX_UINT): + charge_state(NX_INT): + charge_state_analysis(NXapm_charge_state_analysis): + exists: optional + config(NXparameters): + nuclides(NX_UINT): + mass_to_charge_range(NX_FLOAT): + min_half_life(NX_FLOAT): + min_abundance(NX_FLOAT): + sacrifice_isotopic_uniqueness(NX_BOOLEAN): + charge_state(NX_INT): + nuclide_hash(NX_UINT): + mass(NX_FLOAT): + natural_abundance_product(NX_FLOAT): + shortest_half_life(NX_FLOAT): + mass_to_charge_range(NX_FLOAT): + nuclide_list(NX_UINT): + exists: recommended + name(NX_CHAR): + exists: recommended + iontypes(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + The iontype identifier for each ion that was best matching; + stored in the order of the evaporation_id. + + The value zero is reserved for documenting that an ion was unranged. + Identifier for ranged ions need to start at 1 up to number_of_ion_types. + dimensions: + rank: 1 + dim: (n,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7dc62384d7e42be7e77a61245f222c63c94a65b9e296fd90898b192b722152d0 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of hit qualities, the so-called hit types, distinguished. +# +# +# +# +# Number of delay-line-detector (DLD) wires of the detector. +# +# +# +# +# Number of bins used in the mass-to-charge-state-ratio spectrum. +# +# +# +# +# Number of pulses collected in between start_time and end_time resolved by an +# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of +# ions included in the reconstructed volume if the application definition is used +# to store results of an already reconstructed dataset. +# +# +# +# +# Number of pulses returned by the hit_finding algorithm. +# Neither necessarily equal to p nor to n. +# +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# from which an instance of a reconstructed volume has been generated. +# These ions get new identifier assigned in the process, the so-called +# evaporation_id. This identifier must not be confused with the pulse_id. +# This value is typically smaller than both p and p_out. +# +# +# +# +# Number of mass resolution values. +# +# +# +# +# Application definition for real or simulated atom probe and field-ion microscopy experiments. +# +# Atom probe tomography and field-ion microscopy are methods for characterizing materials +# through induced controlled extraction of individual atoms as ions and molecular ions from +# a sharp needle-shaped specimen. +# +# Offering isotopic and nanometer-scale resolution, atom probe data enable quantification of +# local chemical composition and computing of volumetric reconstructions which are models for +# the atomic architecture of the small specimen volume analyzed. These reconstructions provide +# input for characterization of atomic segregation at crystal defects. The term microstructural features +# is considered as a narrow synonym for crystal defects. +# +# The aim of the NXapm application definition is to provide a general yet specific enough +# solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments. +# +# Before summarizing the design of the base classes and the parts of the NXapm application definition, +# it is worthwhile to recall and distinguish concepts that are related to atom extraction +# events and the molecular ions that are frequently generated by the sequence of events: +# +# * An atom probe instrument uses laser or voltage pulsing events to trigger ion extraction events. +# * These ions are accelerated in an electric field towards a position-sensitive detector system. +# Physical events and corresponding signal on this detector is triggered by an ion hitting the detector. +# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. +# * Note that only a part the specimen volume can be measured and finite detection efficiency means that +# not all atoms in the measured volume will be detected. Neutral atoms can escape detection. Some ions +# escape detection because they hit into walls of the analysis_chamber. +# +# Raw data are typically processed as follows: +# +# * Detector pulses and their timing are processed and discriminated into signal events of different quality levels. +# High quality events might be considered in further processing to identify the corresponding molecular ion +# and its original position in the reconstructed volume. +# * Signal calibration and filtering steps are applied to convert raw time-of-flight data to calibrated +# mass-to-charge state ratio values and obtain calibrated impact positions on the detector. +# * Ranging and identifying an ion that corresponds to each detector event. +# Isotopic abundance and theoretical models inform these ranging algorithms. +# * Finally, such selected ion impact positions and iontypes are used to compute a reconstructed volume of +# the specimen using backprojection algorithms. In effect, an atom probe measurement is a combination of +# a data acquisition and a data analysis workflow. +# +# Not only in AMETEK/Cameca's APSuite/IVAS software, which the majority of atom probers use, these concepts +# are well distinguished. However, the algorithms used to transform correlations between pulses and physical +# events into actual events, the so-called detector hits of ions, is a proprietary one. This algorithm is also +# referred to as the hit finding algorithm. +# +# Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting +# schema where the course of the specimen evaporation is documented such that quantities are a function of +# evaporation_id i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. +# That is the evaporation_id values take the role of an implicit time and course of the experiment given that +# ion extraction physically is a sequential process. +# +# This application definition includes fields that the atom probe community has decided to represent best practices +# for reporting atom probe measurements. Exemplar mapping tables are provided for documents that reported these +# best practices to translate technical term into concepts of the NXapm application definition. +# +# *The NeXus application definition NXapm defines a hierarchical data model with ten building blocks:* +# +# The data model represents a tree of concepts. The tree is constructed from groups of concepts representing +# the branches, together with fields and attributes representing leaves. NXapm is defined by composing and +# specializing base classes into the following ten categories: +# +# - The field ``definition`` specifies that the data schema is NXapm. In combination with +# administrative metadata such as the attribute ``NeXus_version`` provided by :ref:`NXroot` this +# specifies which version of NXapm the instance data in a NeXus/HDF5 file are compliant with. +# - The fields ``run_number``, ``experiment_alias``, ``experiment_description`` and +# the group ``userID`` provide concepts for storing organizational metadata that +# contextualize the work within the research workflow and humans involved in this. +# - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. +# - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations or notes +# that are associated with the data, i.e. other artifacts that are deemed relevant when reporting about +# a measurement or simulation. These groups are useful when NXapm is used as a serialization format for +# technology-partner-agnostic archival of data and metadata that have been collected during a session with +# an atom probe instrument. The terms run and session are understood as exact synonyms that refer to an +# uninterrupted period of measurement. Resuming measurement on a specimen after an interruption is viewed +# as a new run and the new data should not be appended to the previous run, but written to either a new NXentry, +# or a new file. Removing the specimen from the instrument is an interruption. Changing evaporation conditions +# while the specimen is remains in the analysis_chamber and resuming thereafter the measurement +# is not considered as an interruption. It is a common strategy to probe the evaporation process for different +# instrument parameters. Each individual collection should then though be stored in an own NXevent_data_apm +# group. Parking the specimen to the buffer_chamber and resuming the measurement at a later stage is an interruption. +# During a run, the microscope is used for a certain amount of time to characterize a single specimen. +# - The groups ``sample`` and ``specimen`` provide concepts for storing metadata about the sample and the specimen, +# i.e. the smaller part that was removed from the sample to be measured in the atom probe session. +# The term "tip" in the context of atom probe research is considered jargon. +# Specimen is an exact synonym for tip. +# - The field ``operation_mode`` and group ``measurement`` provides concepts that +# are useful for describing a measurement during a session with an atom probe or field-ion microscope. +# This includes the chain of events of data and metadata that were collected during such a session. +# - The group ``simulation`` provides concepts that are useful for describing a simulation of an +# atom extraction, ionization, and ion trajectory simulation. Combined with ``measurement`` +# this provides a data schema for defining a digital twin of the instrument and its setup. +# - The groups ``consistent_rotations``, and ``NAMED_reference_frame`` provide concepts for +# reporting coordinate systems (frames of reference) and rotation conventions that clarify how data +# should be interpreted specifying the rotation of orientable objects in the microscope, its components, +# or of crystals and crystal defects in the material analyzed. +# - The group ``atom_probeID`` provides concepts for the computational workflows that were +# used to convert raw detector data into reconstructed ion positions and documentation of +# ranging definitions made. +# - The group ``profiling`` provides concepts for reporting computational details such as +# programs and libraries used, for documenting the libraries of virtual environments such as those used +# by conda or python virtual environment, including details about the computing hardware used, and +# documenting capabilities for performance analyses and benchmarking of the software or its parts. +# +# *Design choices:* +# +# Given that most atom probe instruments across the globe were built by AMETEK/Cameca and are delivered +# with the AP Suite/IVAS software there is some homogeneity in how a measurement is performed and which data +# artifacts and algorithms used for data processing. Complementary use of open-source software specifically for +# the reconstruction, ranging, and later data processing stages contributes to a landscape of multiple tools in use. +# Therefore, communication of atom probe research differs between user groups. This holds even more so true +# for the sub community in atom probe which study physical mechanisms involved during ionization to the point that +# here that almost each research work defines different simulation tools with different types of data artifacts. +# +# NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to +# offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended +# but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex +# use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the +# optional group ``measurement`` with its required child ``measurement/instrument``: +# Users which report simulations are not forced to document the instrument but users which have characterized +# a specimen are motivated to report about the instrument. They are though not necessarily required to report all +# the details of the instruments' components because the design pattern is applied recursively. +# +# *NXapm distinguishes and stores instance data based on how long they remain unchanged:* +# +# ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. +# The first group is designed for storing metadata about the instrument that do not change over the course of the session. +# Examples are the name of the technology partner who built the microscope or whether a laser or voltage pulser +# and reflectron exists or not. The second group is designed for metadata and data that are collected during +# the session with the instrument. These, are stored as instances of ``measurement/eventID``, +# events that can be time-stamped individually. +# Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose is to +# store those specific state and settings of the instrument that was present during the collection of the event. +# Thereby, changing conditions such as compaigns with different target detection rate can be stored. +# +# Noteworthy, such an approach of the atom probe detecting groups of events and storing these as groups has also +# been in use in the proprietary software via CamecaRoot, a set of customized data structures and file formats that use +# the CernRoot library. By virtue of design this reduces unnecessary repetition of metadata stored in the first group. +# +# ``atom_probeID`` offer classes for the each task relevant task in the data processing pipeline that converts raw detector +# event data to calibrated mass-to-charge-state-ratio values and hit_position on the detector. These include +# ``initial_specimen``, and ``final_specimen`` locations for storing images of the specimen prior/after the measurement as +# considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the +# hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about +# to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations +# and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the +# conversion from time-of-flight to mass-to-charge-state-ratio values. +# +# Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how +# from all the previous sources of input one can compute a reconstructed volume, and apply peak fitting routines on the +# mass-to-charge-state-ratio histogram to label ions, i.e. range them for their isotopic identity. +# Group ``atom_probeID/reconstruction/naive_discretization`` offers a standardized way to report simple +# three-dimensional histograms. Group ``atom_probeID/ranging/peak_identification/ionID`` and its +# complementing group ``atom_probeID/ranging/peak_identification/ionID/charge_state_analysis`` +# solves the issue that the ranging definitions in classical file formats are not reported for always for their isotopic identity +# and charge state. The field ``atom_probeID/ranging/peak_identification/iontypes`` provides a place for +# storing a compact representation of the results of each ranging definition made at the level of each ion. +# +# *The compatibility of NXapm and NXem:** +# +# The design of NXapm mirrors that of :ref:`NXem`. This was an intentional choice to support the increasingly stronger connection between +# these two materials characterization methods, especially in light of recent advances in the direct coupling of atom probe and +# transmission electron microscopes and scanning transmission electron microscopes. +# +# +# +# +# +# +# +# +# +# +# The configuration of the software that was used to generate this NeXus file. +# +# +# +# A collection of all programs and libraries which are considered relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# The identifier whereby the experiment is referred to in the control software. +# +# It is common practice in atom probe research to refer to a measurement on a single +# specimen as a run. When working with AMETEK/Cameca instruments it is a common +# practice also to store all data associated with such a run in files whose name +# is composed from a prefix that details the type of instrument (e.g. R5076) followed +# by the run_number. These filenames are often used as the specimen_name or +# experiment_identifier. The terms run and session are understood as exact synonyms. +# +# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, +# or the instruments at GPM in Rouen, use the identifier which matches +# best conceptually 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; provided these +# RHIT or HITS files respectively are stored alongside a data artifact. +# With NXapm the RHIT or HITS can be stored via NXnote in the +# hit_finding algorithm section. +# +# 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. Such interrupted runs +# should be stored as individual :ref:`NXentry` instances in one NeXus file. +# +# +# +# +# Alias or short name which scientists can use to refer to this experiment. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into the field. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the atom probe session started. If the exact duration of +# the measurement is not relevant, start_time only should be used. +# +# The start_time is required in order to ensure that at least one point in time +# is provided for full temporal context to a measurement and simulation +# when writing instance data using NXapm. Otherwise, the instance data +# can not be sorted in order or even placed in a logical sequence to other +# steps of the research workflow, which would disallow using functionalities +# in research data management systems that rely on temporal context. +# +# Specifying start_time and end_time is useful for capturing more detailed +# bookkeeping 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. For this +# purpose the :ref:`NXevent_data_apm` instance should be used. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the atom probe session ended. +# +# Writing the end_time can be a tricky in practice. If written at the start +# of the experiment, it can only be an estimate. If written at the end, there +# is the risk for having the computer crash or lose power. The absence of +# end_time should not be interpreted as that the experiment was aborted. +# Only, the field ``status`` should be used for communicating such abortion. +# +# +# +# +# How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime +# +# +# +# +# +# +# +# +# +# +# +# +# +# What type of atom probe experiment is performed to inform research data management +# systems and allow filtering: +# +# * apt are experiments where the analysis_chamber has no imaging gas. +# Experiments with LEAP instruments are typically with this operation_mode. +# * 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. +# Few experiments of this type have been performed, as it can be detrimental +# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample from which the specimen was prepared or +# site-specifically cut out using e.g. a focused-ion beam instrument. +# +# In NXapm, a measurement is performed on a specimen. Since APM specimens +# are very small, they are typically cut from a larger object with some +# scientific significance, which NXapm refers to as a sample. +# +# +# +# +# False, if the sample is a real one. +# True, if the sample is a virtual one. +# +# +# +# +# Given name/alias for the sample. +# +# +# +# +# Qualitative information about the grain size, here specifically +# described as the equivalent spherical diameter of an assumed +# average grain size for the crystal ensemble. +# +# If the specimen does not contain many crystals average values +# might be an unreliable descriptor. +# +# Reporting a grain size may be useful though as it allows +# judging if specific features are expected to be found in the +# detector hit map. +# +# +# +# +# Magnitude of the standard deviation of the grain_diameter. +# +# +# +# +# An array of elapsed time, the independent axis, of a time-temperature curve. +# +# This field can be used in combination with heat_treatment_temperature and +# heat_treatment_temperature_errors as well as heat_treatment_quenching_rate +# and heat_treatment_quenching_rate_errors respectively. In this case, these fields +# should also be stored as an array with the same dimensions as heat_treatment_time +# to store the dependant axes of a time-temperature curve as well as its first derivative. +# +# +# +# +# If heat_treatment_time is absent, 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 a documentation of the annealing +# treatment as a function of time is available one should better +# rely on this information and have it stored alongside the NeXus file. +# +# If heat_treatment_time is provided, the temperature. +# Consult the docstring of heat_treatment_time. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_temperature. +# +# If heat_treatment_time is provided, the magnitude of the standard derivation of the +# temperature. Consult the docstring of heat_treatment_time. +# +# +# +# +# If heat_treatment_time is absent, the rate of the last quenching step. +# +# Knowledge about this value can give an idea how the sample was heat treated. +# However, there are many situations where one can imagine that the scalar value +# for just the quenching rate is insufficient. +# +# If heat_treatment_time is provided, the first derivative of the time-temperature curve. +# Consult the docstring of heat_treatment_time for further details. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_quenching_rate. +# +# If heat_treatment_time is provided, the magnitude of the standard deviation of +# the first derivative of the time-temperature curve. +# Consult the docstring of heat_treatment_time for further details. +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# Description of the specimen that was cut off from the sample. +# +# In atom probe jargon this is typically referred to as the tip. +# +# +# +# +# False, if the specimen is a real one. +# True, if the specimen is a virtual one. +# +# +# +# +# Given name or an alias. Better use identifierNAME and identifier_parent instead. +# +# A single NXentry should be used only for the characterization of a single specimen. +# +# +# +# +# Identifier of the sample from which the specimen was cut or the string "n/a". +# +# The purpose of this field is to support functionalities for tracking sample +# provenance via a research data management system. +# +# +# +# +# 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. Ideally, this +# matches the last timestamp that is mentioned in the digital resource +# pointed to by identifier_parent. +# +# 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. +# +# +# +# +# List of comma-separated elements from the IUPAC periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources pointed to by identifier_parent or walk through +# eventually deeply nested groups in data instances. +# +# +# +# +# Discouraged free-text field. +# +# +# +# +# True, if the specimen contains a grain or phase boundary. +# False, if the specimen is a single crystal. +# +# +# +# +# True, if the specimen is amorphous. +# False, if the specimen is not. +# +# +# +# +# Ideally measured otherwise best elaborated guess of the initial radius of the +# specimen. +# +# +# +# +# Ideally measured, otherwise best estimate, of the initial 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 smallest angle +# between the specimen space z-axis and a vector on the lateral surface +# of the cone. +# +# +# +# +# +# The conventions used when reporting crystal orientations. +# We follow the best practices of the Material Science community +# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin. +# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several choices e.g. zxz, xyz +# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# The most frequently used convention in Materials Science is zxz, which is based on the work +# of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished +# from Tait-Bryan angles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parametrizations/representations according +# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# +# A coordinate system. Multiple instances require unique names. +# +# Several Euclidean coordinate systems (CS) are used in the field of atom probe: +# +# * 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. +# Suggested name of the group ``laboratory_reference_frame``. +# * The specimen space; +# a CS affixed to either the base or the initial apex of the specimen, +# whose z axis points towards the detector. +# Suggested name of the group ``specimen_reference_frame``. +# * 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. +# Suggested name of the group ``detector_reference_frame``. +# * 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. +# Suggested name of the group ``reconstruction_reference_frame``. +# +# To achieve unique names, the prefix "NAMED" should be replaced to +# with something derived from an alias for the coordinate system, +# or the value of the "alias" field. +# +# Use the suffix _reference_frame when creating specific instances +# of NXcoordinate_system e.g. laboratory_reference_frame, +# reconstruction_reference_frame and so on and so forth. +# +# 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 identifier interval. Typically, the set of +# ion evaporation sequence identifiers 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. +# +# To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A region-of-interest analyzed either during or after the session for which +# specific processed data of the measured or simulated data are available. +# +# If a single instance is required the group should be named atom_probe. +# If multiple groups are required these should be named atom_probe1, atom_probe2, +# and so on and so forth. +# +# +# +# SEM or TEM image of the initial specimen taken before the measurement. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# SEM or TEM image of the final specimen taken after completion of the +# measurement. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Document the control software that was used on the instrument with which raw data +# were collected. +# +# For almost all atom probe instruments, the recorded raw data and metadata follow +# proprietary semantics. Therefore, this group can currently often not be filled with +# more than the control software and some pointing to digital artifacts (e.g. proprietary files) +# that have been collected during the measurement in an effort to document as best as +# possible all steps of an analysis workflow. +# +# The physical quantities measured in an atom probe experiment are time-of-flight and +# tuples of arrival_time_pairs as a function of the event chain on the pulser. +# From these tuples, hits are computed in a process called hit_finding. +# +# +# +# +# The control software that was used for running the measurement. +# +# At least the main software should be reported. If this is the only program +# to report name the group "program" and use its below fields program and +# version to detail the version used. E.g. program AP Suite, version 6.3 +# +# It is recommended to report multiple programs though, i.e. also the libraries +# and dependencies of the software. In the case of AP Suite/IVAS this can be used +# to document the AP Suite GUI, LAS, CamecaRoot, and CernRoot versions. +# In this case always name the program groups program1, program2, ... +# with program one being AP Suite/IVAS. +# +# In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's +# M-TAP instruments, also use program1, program2, ... with program1 representing +# the control software e.g. `M. Monajem and P. Felfer pyCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_. +# Further instances (program2, ...) can be used to list the dependencies, the +# python virtual environment. +# +# +# +# +# +# +# +# Possibility to point to files that contain raw data. +# +# Exemplar files that could be pointed to here when working with +# AMETEK/Cameca instruments are the proprietary STR, RRAW, or HITS +# files that AP Suite/IVAS generates. +# +# +# +# +# +# +# +# +# The number of delay-line-detector (DLD) wires present. +# +# +# +# +# +# +# +# +# +# Alias tuple, typical for the begin and the end of each DLD wire +# of the detector. Order follows arrival_time_pairs. +# +# The order of the first dimension should match that of the +# second dimension of the arrival_time_pairs field. +# +# +# +# +# +# +# +# +# Raw readings from the analog-to-digital-converter +# timing circuits of the detector wires. +# +# +# +# +# +# +# +# +# +# +# The configuration of a hit finding algorithm and its output. +# +# Hit finding is the process of deciding which detector signals are significant +# and assigning specific ions colliding with the detector +# to each observed event. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Evaluated ion impact coordinates on the detector. +# Use the depends_on field to specify which reference +# frame the positions are defined in. +# +# +# +# +# +# +# +# Contains the path to an instance of NX_coordinate_system +# in which the positions are defined. +# +# +# +# +# +# Number of events of type "golden" when APSuite/IVAS was used as the +# software with which the measurement was performed. +# +# The value can be extracted from the CRunHeader.fTotalEventGolden +# field of a CamecaRoot RHIT/HITS file. +# +# +# +# +# Number of events of type "incomplete" when APSuite/IVAS was used as the +# software with which the measurement was performed. +# +# The value can be extracted from the CRunHeader.fTotalEventIncomplete +# field of a CamecaRoot RHIT/HITS file. +# +# +# +# +# Number of events of type "multiple" when APSuite/IVAS was used as the +# software with which the measurement was performed. +# +# The value can be extracted from the CRunHeader.fTotalEventMultiple +# field of a CamecaRoot RHIT/HITS file. +# +# +# +# +# Number of events of type "partials" when APSuite/IVAS was used as the +# software with which the measurement was performed. +# +# The value can be extracted from the CRunHeader.fTotalEventPartials +# field of a CamecaRoot RHIT/HITS file. +# +# +# +# +# Number of events when APSuite/IVAS was used as the +# software with which the measurement was performed. +# +# The value can be extracted from the CRunHeader.fTotalEventRecords +# field of a CamecaRoot RHIT/HITS file. +# +# +# +# +# Hit quality is an integer that specifies which category/type a hit was assigned to. +# This field lists the human-readable, possibly though proprietary types distinguished. +# The indices of this array are used in hit_quality to encode hit_quality for each +# pulse in a more efficient way than by repeating the string that is used for each +# type as it is provided in this field. +# +# As an example, assume two types, "golden" and "partial", are distinguished. +# If hit_quality_type stores the array "golden", "partial", the index 0 +# in hit_quality identifies all those pulses of category "golden", +# while the index 1 in hit_quality identifies all of category "partial". +# +# +# +# +# +# +# +# Hit quality identifier for each pulse. +# Identifier has to be within hit_quality_type. +# +# +# +# +# +# +# +# The number of ions determined to have been collected on the same pulse. +# These ions may hit different pixels, or even the same detector pixel. +# The hit_multiplicity is not related to the makeup of the ions and should not be +# confused with the number of atoms or elements that constitute a molecular ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Integer which defines the first evaporation_id. +# Typically, this is either zero or one. +# +# +# +# +# There are two possibilities to report evaporation_id values: +# +# If evaporation_id_offset is provided, the evaporation_id values are defined +# by the sequence :math:`[evaporation\_id\_offset, evaporation\_id\_offset + n]` +# with :math:`n` the number of ions in the reconstructed volume. +# +# Alternatively, evaporation_id_offset is not provided but instead a +# a sequence of :math:`n` values is defined, these integer values +# do not need to be sorted. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. +# +# The voltage-and-bowl correction is a data post-processing step to correct ion impact +# positions for flight path differences, detector bias, and nonlinearities. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference mass-to-charge state ratio value +# +# For example 16 Da as mentioned by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# +# +# +# +# +# Raw time-of-flight data without corrections. +# +# +# +# +# +# +# +# The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate +# +# +# +# +# Calibrated time-of-flight. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Mass calibration with unit peaks/interp. as mentioned by `T. Blum et al. +# <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# +# +# +# +# Inverse of the mass resolution :math:`\frac{M}{\Delta M}` as mentioned by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# +# Multiple values can be reported but reporting each is only useful when stating also: +# +# * The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. +# Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). +# Consequently, mass_resolution_fw should needs to be a vector of the same length +# and using the same order like used for mass_resolution, i.e. the first mass resolution was +# defined at the maximum as defined by the first value from mass_resolution_fw. +# * The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` +# As many instances of mass_resolutionION should be used with instances +# numbered starting from 1 up to the length of the mass_resolution vector. +# +# +# +# +# +# +# +# The full width at which :math:`{\Delta M}_{fw}` fraction of maximum this value was defined. +# Examples are at tenth :math:`{\Delta M}_{10}` or at half maximum (FWHM). +# Consequently, mass_resolution_fw should needs to be a vector of the same length +# and using the same order like used for mass_resolution, i.e. the first mass resolution was +# defined at the maximum as defined by the first value from mass_resolution_fw. +# +# +# +# +# +# +# +# The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` +# As many instances of mass_resolutionION should be used with instances +# numbered starting from 1 up to the length of the mass_resolution vector. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For LEAP and APSuite/IVAS-based analyses the root file which stores +# the settings whereby an RHIT/HITS file can be used to regenerate the +# reconstructed volume that is here referred to. +# +# The respective RHIT/HITS file should ideally be specified in the serialized +# group of the hit_finding section of this application definition. +# +# +# +# +# +# +# +# +# For LEAP and APSuite/IVAS-based analyses the resulting typically +# file with the reconstructed positions and calibrated mass-to-charge- +# state ratio values. +# +# For other data collection/analysis software the data artifact which comes +# closest conceptually to AMETEK/Cameca's typical file formats. +# +# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, +# which should be stored alongside this record in the research data +# management system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The respective ranging definitions file RNG/RRNG/ENV/HDF5. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# (Out-of-sync, time-independent) background levels in ppm/ns +# reported by e.g. APSuite/IVAS for LEAP systems. +# +# +# +# +# The mass-resolving power (MRP) value +# +# `D. Larson et al. <https://doi.org/10.1007/978-1-4614-8721-0>`_ report Eq. D.8 in page 282: +# +# :math:`MRP = \frac{1}{2\delta t} \cdot \sqrt{\frac{m}{n}\frac{1}{2eV}L}`, +# +# with :math:`\delta t` representing the timing imprecision, :math:`\frac{m}{n}` the mass-to-charge state ratio, +# :math:`e` the elementary charge, :math:`V` the potential difference, and :math:`L` the flight path length. +# +# Timing imprecision is caused by variations of flight path length and voltage, +# the fact that the precision of electronics is finite and a spread of the +# time-of-departure of individual ions is observed. +# +# +# +# +# Mass-to-charge state ratio :math:`\frac{m}{n}` at which mrp_value was specified. +# +# +# +# +# Potential difference :math:`V` at which mrp_value was specified. +# +# +# +# +# Flight path length :math:`L` at which mrp_value was specified. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Category for the peak offering a qualitative statement of the location of the peak +# in light of limited mass-resolving power that is relevant for +# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ +# for examples of each category: +# +# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` +# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` +# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states +# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` +# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` +# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Ions that were ranged. +# +# The value zero is reserved for documenting that an ion was unranged. +# Identifier for ranged ions need to start at 1 up to number_of_ion_types. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The iontype identifier for each ion that was best matching; +# stored in the order of the evaporation_id. +# +# The value zero is reserved for documenting that an ion was unranged. +# Identifier for ranged ions need to start at 1 up to number_of_ion_types. +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index e0b8907b34..68c87a0e66 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -1,4 +1,4 @@ - + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of ion candidates. + + + + + Maximum number of allowed atoms per ion. + + + + + Number of entries + + + + + Base class to document the parameters, configuration, and results of a processing for recovering + the charge state and nuclide composition of an ion from ranging definitions as used in the research + field of atom probe microscopy. + + A ranging definition classically reports only the mass-to-charge-state-ratio interval plus the + elemental composition, but not necessarily the nuclide that compose the ion. + + As the mass-resolving-power in an atom probe instrument is finite and typically lower + than for cutting edge tandem mass spectrometry it is possible that different combinations of nuclides + are indistinguishable and thus multiple ions in eventually even different charge states can be valid + labels for a given mass-to-charge-state-ratio peak. Enumerating the possible combinations + is a programmatic approach that can help with peak identification. + + + + Parameters for the algorithm used to recover which combinations of nuclides + have a mass and charge that matches a set of constraints. + + Each parameter in this group is defines one constraint. + + + + Parameter that defines the elements considered in the combinatorial search. + The array contains nuclides as many times as their multiplicity and must not be empty. + Nuclides are encoded using the hashing rule that is defined in by nuclide_hash of :ref:`NXatom`. + + Constraining the elements or nuclides instead of providing all nuclides + reduces the time to perform an exhaustive combinatorial search. + + + + + + + + Parameter that defines the interval :math:`[{\frac{m}{q}}_{min}, {\frac{m}{q}}_{max}]` within which + ions with given mass-to-charge-state-ratio qualify as candidates. + + + + + + + + Parameter that defines the minimum half life for how long each nuclide of each + ion needs to be stable such that the ion qualifies as a candidate. + + + + + Parameter that defines the minimum natural abundance of each nuclide of each + ion such that the ion qualifies as a candidate. + + + + + If the value is false, it means that non-unique solutions are accepted. + These are solutions where multiple candidates have been built from + different nuclide instances but the charge_state of all the ions is the same. + + + + + + Signed charge, i.e. integer multiple of the elementary + charge of each candidate. + + + + + + + + Table of nuclide instances of which each candidate is composed. + Each row vector is sorted in descending order. + Unused entries in the matrix should be set to 0. + Use the hashing rule that is defined in nuclide_hash of :ref:`NXatom`. + + + + + + + + + Accumulated mass of the nuclides in each candidate. + Not corrected for quantum effects. + + + + + + + + The product of the natural abundances of the nuclides for each candidate. + + + + + + + + For each candidate the half life of the nuclide that has the + shortest half life. + + + + + + diff --git a/base_classes/NXapm_measurement.nxdl.xml b/base_classes/NXapm_measurement.nxdl.xml new file mode 100644 index 0000000000..c536a2daf1 --- /dev/null +++ b/base_classes/NXapm_measurement.nxdl.xml @@ -0,0 +1,70 @@ + + + + + + Base class for collecting a run with a real or a simulated atom probe or field-ion microscope. + + The term run is understood as an exact synonym for session, i.e. the usage of a real or simulated + tomograph or microscope for a certain amount of time during which one characterizes a single specimen. + + Research workflows for experiments and simulations of atom probe and related field-evaporation + evolve continuously and become increasingly connected with other methods used for material + characterization specifically electron microscopy. A few examples in this direction are: + + * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ + * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ + * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ + * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ + + The majority of atom probe research is performed using the so-called Local Electrode Atom Probe (LEAP) instruments + from AMETEK/Cameca. In addition, several research groups have built their own instruments and shared different + aspects of the technical specifications and approaches including how these groups apply data processing e.g.: + + * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ + * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ + * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ + + to name but a few. + + + + A statement whether the measurement completed successfully, or was aborted. + + + + + + + + + Statement about the quality of the measurement. + + The value can be extracted from the CAnalysis.CResults.fQuality + field of a CamecaRoot ROOT file. + + + + + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml new file mode 100644 index 0000000000..86ac98719f --- /dev/null +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -0,0 +1,118 @@ + + + + + + Base class for the configuration and results of ranging definitions. + + Ranging is a data post-processing step used in the research field of + atom probe during which elemental, isotopic, and/or molecular identities + are assigned to mass-to-charge-state ratios within certain intervals. + The documentation of these steps is based on ideas that + have been 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>`_ + + + + + + Specifies the mass-to-charge-state ratio histogram. + + + + + Smallest :math:`{\frac{m}{q}}_{min}` mass-to-charge-state ratio value. + + The lower (left-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. + + + + + Largest :math:`{\frac{m}{q}}_{max}` mass-to-charge-state ratio value. + + The upper (right-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. + + + + + The number of bins on the interval :math:`[{\frac{m}{q}}_{min}`, + {\frac{m}{q}}_{max}]`. + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + Details of the background model that was used to + correct the total counts per bin into counts. + + + + + Free-text field to describe how atom probers define a background model. + + Thereby, community feedback can be collected to inform an improved + version of this base class in the future. + + + + + + How were peaks in the mass-to-charge-state ratio histogram identified. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + 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 representing a reserved value. + + Consequently, start counting iontypes from 1. + + + + + Assumed maximum value that suffices to store all relevant molecular ions, + even the most complicated ones that one can typically observe and distinguish + typically. Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). + + + + + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml new file mode 100644 index 0000000000..43068bd667 --- /dev/null +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -0,0 +1,275 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process - the so-called + evaporation_id, which must not be confused with the pulse_id! + + + + + Base class for the configuration and results of a reconstruction algorithm. + + Generating a tomographic reconstruction of the specimen uses selected and + 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. + + + + + + + Parameters that configure a reconstruction algorithm which takes + hit data and mass-to-charge-state ratio values to construct a model + of the evaporated specimen. This model is called the reconstructed volume. + Researchers in the field of atom probe call these algorithms reconstruction + protocols. + + Different such protocols exist. Although these are qualitatively similar, + each protocol uses and interprets the parameters slightly differently. + + The majority of reconstructions is performed with the proprietary software + APSuite / IVAS, the source code for the reconstruction protocols that this + software implements in detail is not open but the parameters and their qualitative + effect on the reconstructed volume follows the protocols that are discussed in + the atom probe literature. This group allows to document these parameters in + a standardized manner. + + + + Lowest voltage at which an ion that is considered in the reconstructed + volume has been extracted from the specimen. + + + + + Highest voltage at which an ion that is considered in the reconstructed + volume has been extracted from the specimen. + + + + + Qualitative statement about which reconstruction protocol was used. + + For reconstructions performed with APSuite / IVAS the value "cameca" + should be used. + + + + + + + + + + + Assumed primary element based on which the reconstruction is calibrated. + + The value can be extracted from the CAnalysis.CSpatial.fPrimaryElement + field of a CamecaRoot ROOT file. + + + + + Assumed detection efficiency + + The value can be extracted from the CAnalysis.CSpatial.fEfficiency + field of a CamecaRoot ROOT file. + + + + + Nominal flight path + + The value can be extracted from the CAnalysis.CSpatial.fFlightPath + field of a CamecaRoot ROOT file. + + + + + Assumed evaporation electric field + + The value can be extracted from the CAnalysis.CSpatial.fEvaporationField + field of a CamecaRoot ROOT file. + + + + + Image compression factor (ICF) + + The value can be extracted from the CAnalysis.CSpatial.fImageCompression + field of a CamecaRoot ROOT file. + + + + + Sum of ion volumes + + The value can be extracted from the CAnalysis.CSpatial.fKfactor + field of a CamecaRoot ROOT file. + + + + + Shank angle + + The value can be extracted from the CAnalysis.CSpatial.fShankAngle + field of a CamecaRoot ROOT file. + + + + + Assumed atomic volume + + + + + The value can be extracted from the CAnalysis.CSpatial.fTipRadius + field of a CamecaRoot ROOT file. + + + + + The value can be extracted from the CAnalysis.CSpatial.fTipRadius0 + field of a CamecaRoot ROOT file. + + + + + The value can be extracted from the CAnalysis.CSpatial.fVoltage0 + field of a CamecaRoot ROOT file. + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. Therefore, we collect first such + feedback before parametrizing this further. + + If no crystallographic calibration was performed, the field + should be filled with the n/a, meaning not applied. + + + + + Possibility of a free text field that allows to report additional details related to + the reconstruction protocol. For LEAP systems and reconstructions that are + performed with APSuite / IVAS see also `B. Gault et al. <https://doi.org/10.1093/mam/ozae081>_` + and `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). + for best practices on the reporting of metadata in atom probe tomography. + + + + + + + Three-dimensional positions of the ions in the reconstructed volume. + + + + + + + + The instance of :ref:`NXcoordinate_system` in which the positions are defined. + + + + + + + + + Visual overview of the reconstructed dataset via a three-dimensional + histogram of ion counts. Ion counts are characterized using one nanometer + cubic bins without applying any smoothening of reconstructed positions + during the histogram computation. + + Such preview is useful to get an impression of the macroscopic shape of the + reconstructed volume. Visualizing by ion counts highlights density variations + the reconstructed volume that are signatures of features such as poles, + interfaces or irregularities of the specimen shape. + + + + + + Sum of ion volumes + + The value can be extracted from the CAnalysis.CSpatial.fRecoVolume + field of a CamecaRoot ROOT file. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. The physical specimen cannot be measured completely + because ions may launch but hit in locations other than the detector. + + + + + Tight, axis-aligned bounding box about the point cloud of the reconstruction. + + + + Minimum coordinate value along the x-direction + + + + + Maximum coordinate value along the x-direction + + + + + Minimum coordinate value along the y-direction + + + + + Maximum coordinate value along the y-direction + + + + + Minimum coordinate value along the z-direction + + + + + Maximum coordinate value along the z-direction + + + + diff --git a/base_classes/NXapm_simulation.nxdl.xml b/base_classes/NXapm_simulation.nxdl.xml new file mode 100644 index 0000000000..cd726f04c7 --- /dev/null +++ b/base_classes/NXapm_simulation.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + Base class for simulation of ion extraction from matter via laser and/or voltage + pulsing. + + + + + + diff --git a/base_classes/NXatom.nxdl.xml b/base_classes/NXatom.nxdl.xml new file mode 100644 index 0000000000..e8f2a55598 --- /dev/null +++ b/base_classes/NXatom.nxdl.xml @@ -0,0 +1,218 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of atom positions. + + + + + Dimensionality + + + + + Maximum number of atoms/isotopes allowed per ion. + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Base class for documenting a set of atoms. + + Atoms in the set may be bonded. The set may have + a net charge to represent an ion. + An ion can be a molecular ion. + + + + Given name for the set. + + This field could for example be used in the research field + of atom probe tomography to store a standardized human-readable + name of the element or ion like such as Al +++ or 12C +. + + + + + Given numerical identifier for the set. + + The identifier zero is reserved for the special unknown ion type. + + + + + Identifier used to refer to if the set of atoms represents a substance. + + + + + + + + Signed net (partial) charge of the (molecular) ion. + + Different methods for computing charge are in use. + Care needs to be exercised with respect to the integration. + `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. + + + + + Charge reported in multiples of the charge of an electron. + + For research using atom probe tomography the value should be set to + zero if the charge_state is unknown and irrecoverable. This can happen + when classical ranging definition files in formats like RNG, RRNG are used. + These file formats do not document the charge state explicitly but only + the number of atoms of each element per molecular ion surplus the + respective mass-to-charge-state-ratio interval. + + Details on ranging definition files in the literature are `M. K. Miller <https://doi.org/10.1002/sia.1719>`_. + + + + + Assumed volume affected by the set of atoms. + + Neither individual atoms nor a set of cluster of these have a volume + that is unique as a some cut-off criterion is required. + + + + + Index for each atom at locations as detailed by position. + Indices can be used as identifier and thus names for individual atoms. + + + + + + + + Nuclide information for each atom at locations as detailed by position. + + One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information + efficiently is via individual hash values. + Consult the docstring of ``nuclide_hash`` for further details. + + + + + + + + Position of each atom. + + + + + + + + Path to a reference frame in which positions are defined + to resolve ambiguity when the reference frame is different + to the NeXus default reference frame (McStas). + + + + + + Relative occupancy of the atom position. + + This field is useful for specifying the atomic motif in + instances of :ref:`NXunit_cell`. + + + + + + + + Vector of nuclide hash values. The vector is sorted in decreasing order. + + Individual hash values :math:`H` `encode <https://doi.org/10.1017/S1431927621012241>`_ + for each nuclide or element the number of protons :math:`Z` and a constant :math:`c` + via the following hashing rule :math:`H = Z + c \cdot 256` . :math:`Z and c` must be 8-bit unsigned integers. + + The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. + The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. + + Exemplified for hydrogen (meaning irrespective which isotope), its hash value is :math:`H = 1 + 255 \cdot 256 = 65281`. + Exemplified for the :math:`^{1}H` hydrogen isotope (:math:`Z = 1, N = 0`), its hash value is :math:`H = 1 + 0 \cdot 256 = 1`. + Exemplified for the :math:`^{2}H` deuterium isotope (:math:`Z = 1, N = 1`), its hash value is :math:`H = 1 + 1 \cdot 256 = 257`. + Exemplified for the :math:`^{3}H` tritium isotope (:math:`Z = 1, N = 2`), its hash value is :math:`H = 1 + 2 \cdot 256 = 513`. + Exemplified for the :math:`^{99}Tc` technetium isotope (:math:`Z = 43, N = 56`), its hash value is :math:`H = 43 + 56 \cdot 256 = 14379`. + The special hash value :math:`0` is a placeholder. + + This hashing rule implements a bitshift operation. The benefit is that this enables encoding of all + currently known nuclides and elements efficiently into an 16-bit unsigned integer. Sufficient + unused indices remain to case situations when new elements will be discovered. + + + + + + + + Table which decodes the entries in nuclide_hash into a human-readable matrix + instances for either nuclids or elements. Specifically, the first row specifies the + nuclide mass number. When the nuclide_hash values are used this means + the row should report the sum :math:`Z + N` or 0. The value 0 documents that + an element from the IUPAC periodic table is meant. + The second row specifies the number of protons :math:`Z`. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a column vector (14, 6). + The array is stored matching the order of nuclide_hash. + + + + + + + + + Associated lower :math:`{\frac{m}{q}}_{min}` and upper :math:`{\frac{m}{q}}_{max}` bounds of the + mass-to-charge-state ratio interval(s) :math:`[{\frac{m}{q}}_{min}, {\frac{m}{q}}_{max}]`. + (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` + steps of indexing a ToF/mass-to-charge-state ratio histogram. + + + + + + + diff --git a/base_classes/NXchemical_composition.nxdl.xml b/base_classes/NXchemical_composition.nxdl.xml new file mode 100644 index 0000000000..d1f0f91639 --- /dev/null +++ b/base_classes/NXchemical_composition.nxdl.xml @@ -0,0 +1,93 @@ + + + + + + + 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. + + + + 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 which are of a particular type. + By contrast, weight_percent normalization factorizes in the + respective mass of the elements. Software libraries that work with + units, like pint in Python, are challenged by these differences as + at.-% and wt.-% are both fractional quantities. + + + + + + + + + Total formula mass or number of atoms, depending on the + normalization stated in the normalization field. + + + + + + + + If this group is used to report the composition of elements from the periodic table, + the group should use the chemical symbol of that element. For other case the + group name is unconstrained. + + + + Count or weight which, when divided by total yields the composition + of this element, isotope, molecule, or ion. + + + + + + + + Composition value for the element/ion referred to under name. + Composition is reported either normalized for atomic or weight + percent. The field normalization should be used to communicate + this explicitly. Composition should be reported consistently + for all instances ELEMENT. + + + + + Magnitude of the standard deviation of the composition. + + + + diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..23bd777d5c --- /dev/null +++ b/base_classes/NXcircuit.nxdl.xml @@ -0,0 +1,152 @@ + + + + + + Base class for documenting circuit devices. + + Electronic circuits are hardware components that connect several electronic components to achieve + specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. + + + + Hardware where the circuit is implanted; includes information about the + hardware manufacturers and type (e.g. part number) + All the elements below may be single numbers of an array of values with length N_channel + describing multiple input and output channels. + + + + + List of components used in the circuit, e.g., resistors, capacitors, transistors or any + other complex components. + + + + + Description of how components are interconnected, including connection points + and wiring. + + + + + Details of the power source for the circuit, including voltage and current + ratings. + + + + + Type of signal (input signal) the circuit is designed to handle, e.g., analog, + digital, mixed-signal. + + + + + + The operating frequency of the circuit, see also bandwidth, which is possibly + but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth + amplifier at low, audio frequencies 1 - 20,000 Hz). + + + + + The bandwidth of the frequency response of the circuit. + + + + + + Input impedance of the circuit. + + + + + Output impedance of the circuit. + + + + + Gain of the circuit, if applicable, usually all instruments have a gain + which might be important or not. + + + + + Root-mean-square (RMS) noise level (in current or voltage) + in the circuit in voltage or current. + + + + + Operating temperature range of the circuit. + + + + + Calibration data for the circuit. + + + + + Offset value for current or voltage. + + + + + Number of output channels connected to this circuit. Most probably N_channel. + + + + + Type of output signal, e.g., voltage, current, digital. + + + + + Power consumption of the circuit per unit time. + + + + + Status indicators for the circuit, e.g., LEDs, display readouts. + + + + + Protection features built into the circuit, e.g., overvoltage protection, + thermal shutdown. + + + + + Updated rate for several processes using the input signal, e.g., History Graph, the circuit + uses for any such process. + + + + + The rate at which the signal changes when ramping from the starting + value. + + + diff --git a/base_classes/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml index 85ea0f7b81..d94bd41e56 100644 --- a/base_classes/NXcomponent.nxdl.xml +++ b/base_classes/NXcomponent.nxdl.xml @@ -1,4 +1,4 @@ - + + + + Base class for reporting the description of a computer + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + A globally unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + Multiple instances should be named processor1, processor2, etc. + + + + + Multiple instances should be named memory1, memory2, etc. + + + + + Multiple instances should be named storage1, storage2, etc. + + + diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml new file mode 100644 index 0000000000..c4e453e028 --- /dev/null +++ b/base_classes/NXcs_filter_boolean_mask.nxdl.xml @@ -0,0 +1,86 @@ + + + + + + + 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. + + + + + Base class for packing and unpacking booleans. + + The field mask should be constructed from packing a vector of booleans + (a bitfield) into unsigned integers with bytesize bitdepth. Padding to + an integer number of such integers is assumed. + + Thereby, this base class can be used to inform software about necessary modulo + operations to decode the mask to recover e.g. set membership of objects in sets + whose membership has been encoded as a vector of booleans. + + This is useful e.g. when processing object sets such as point cloud data. + If e.g. a spatial filter has been applied to a set of points, we may wish to document + memory-space efficiently which points were analyzed. An array of boolean values + is one option to achieve this. A value is true if the point is included and false otherwise. + + + + Possibility to refer to which set this mask applies. + + If depends_on is not provided, it is assumed that the mask + applies to its direct parent. + + + + + 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 content of the mask. If padding is used, + padding bits have to be set to 0. + + + diff --git a/base_classes/NXcs_memory.nxdl.xml b/base_classes/NXcs_memory.nxdl.xml new file mode 100644 index 0000000000..0dfa2e171f --- /dev/null +++ b/base_classes/NXcs_memory.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + Base class for reporting the description of the memory system of a computer. + + + + Typically, computers have multiple instances of memory. + + + + Qualifier for the type of random access memory. + + + + + + + + + Total amount of data which the medium can hold. + + + + diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml new file mode 100644 index 0000000000..28303a0f6b --- /dev/null +++ b/base_classes/NXcs_prng.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of this base class is to identify if exactly the same sequence can be + reproduced, like for a PRNG or not, like for a true physically random source. + + + + Physical approach or algorithm whereby random numbers are generated. + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device whose the state is unpredictable + physically. Some use a strategy of mangling information from the system + clock. Also in this case the sequence is not reproducible without having + additional pieces of information. + + In most cases though so-called pseudo-random number generator (PRNG) + algorithms are used. These yield a deterministic sequence of practically + randomly appearing numbers. These algorithms differ in their quality in + how random the resulting sequences actually are, i.e. sequentially + uncorrelated. 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. + + + + + Parameter of the PRNG controlling its initialization + and thus controlling the specific sequence generated. + + + + + Number of initial draws from the PRNG after its initialized with the seed. + These initial draws are typically discarded in an effort to equilibrate the + sequence. If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/base_classes/NXcs_processor.nxdl.xml b/base_classes/NXcs_processor.nxdl.xml new file mode 100644 index 0000000000..d4d3f7de48 --- /dev/null +++ b/base_classes/NXcs_processor.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + Base class for reporting the description of processing units of a computer. + + Examples are e.g. classical so-called central processing units (CPUs), + coprocessors, graphic cards, accelerator processing units or a system of these. + + + + Typical examples for the granularization of processing units are: + + * A desktop computer with a single CPU; describe using one instance of NXcircuit. + * A dual-socket server; describe using two instances of NXcircuit. + * A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. + + + + General type of the processing unit e.g. + + * pu, processing core or hyper-threading core + * cpu, (multi-)core central processing unit + * gpu, (multi-)core general purpose processing unit + * fpga, field programmable gate array + + + + + + + + + + + Clock speed of the circuit + + + + diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml new file mode 100644 index 0000000000..7905c13e92 --- /dev/null +++ b/base_classes/NXcs_profiling.nxdl.xml @@ -0,0 +1,150 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for performance and profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + 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 and these are used usually by multiple users. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software i.e. an app took. + A frequent idea is here to answer practical questions like how critical is the + effect on the workflow of the scientists, i.e. is the analysis possible in + a few seconds or would it take days if I were to run this analysis on a + comparable machine? + For this more qualitative performance monitoring, mainly the order of + magnitude is relevant, as well as how this was achieved using parallelization + (i.e. reporting the number of CPU and GPU resources used, the number of + processes and threads configured, and providing basic details about the computer). + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks; in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization, i.e. by software and hardware developers as well as for + tracking bugs. Specialized software exists which documents such performance + data in specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions for now. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + 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 demands a more precise record of the wall-clock time. + + + + + The number of nominal processes that the app invoked at runtime. + + The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is one. If the app exclusively uses GPU parallelization, number_of_gpus + can be larger than one. If no GPU is used, number_of_gpus is zero, + even though the hardware may have GPUs installed. + + + + + The number of nominal threads that the app invoked at runtime. + Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + The number of nominal GPUs that the app 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. + ID is an increasing unsigned integer starting at 1. + + + + diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml new file mode 100644 index 0000000000..efcdb60e01 --- /dev/null +++ b/base_classes/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,110 @@ + + + + + + + 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 for a more precise record of the + wall-clock time. + + Elapsed time may contain time portions where resources were idling. + + + + + The number of nominal processes that the app invoked during the execution of this event. + + The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is one. If the app exclusively uses GPU parallelization, number_of_gpus + can be larger than one. If no GPU is used, number_of_gpus is zero, + even though the hardware may have GPUs installed. + + + + + The number of nominal threads that the app invoked at during the execution of this event. + Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + The number of nominal GPUs that the app invoked 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/base_classes/NXcs_storage.nxdl.xml b/base_classes/NXcs_storage.nxdl.xml new file mode 100644 index 0000000000..d4c0a3570b --- /dev/null +++ b/base_classes/NXcs_storage.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Base class for reporting the description of the I/O of a computer. + + + + + Qualifier for the type of storage medium used. + + + + + + + + + + + Total amount of data which the medium can hold. + + + + + Maximum read rate of the storage medium. + + + + + Maximum write rate of the storage medium. + + + + diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 826cd29158..8a87f560f3 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -1,4 +1,4 @@ - + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time. + + + + + Base class to store state and (meta)data of events over the course of an atom probe experiment. + + Having at least one instance for an instance of NXapm is recommended. + + This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs + of atom probe research. Again static and dynamic quantities are split to avoid a duplication + of information. Specifically, the time interval considered is the entire time + starting at start_time until end_time during which we assume the pulser triggered pulses. + These pulses are identified via the pulse_id field. The point in time when each pulse was + fired can be recovered from analyzing start_time and delta_time. + + Which temporal granularity is adequate depends on the situation and research question. + Using a model which enables a collection of events offers the most flexible way to cater for + both atom probe experiments or simulation. To monitor the course of an ion extraction experiment + (or simulation) it makes sense to track time explicitly via time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulse_id. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. + + If users wish 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, the left bound of the time interval, while + the end_time specifies the end, the 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. + + + + + Delta time array which resolves for each pulse_id the time difference + between when that pulse was fired and start_time. + + In summary, using start_time, end_time, delta_time, pulse_id_offset, + and pulse_id provides temporal context information when a pulse was + fired relative to start_time and when it is relevant to translate this into + coordinated world time UTC. + + Note that pulses in reality have a shape and thus additional documentation + is required to assure that the entries in delta_time are always taken at + at points in time that, relative to the triggering of the pulse, represent an + as close as possible state of the pulse. + + + + + + + + Integer which defines the first pulse_id. + Typically, this is either zero or one. + + + + + An integer to identify a specific pulse in a sequence. + + There are two possibilities to report pulse_id values: + If pulse_id_offset is provided, the pulse_id values are defined + by the sequence :math:`[pulse\_id\_offset, pulse\_id\_offset + p]` + with :math:`p` the number of pulses collected in between + start_time and end_time. + + Alternatively, pulse_id_offset is not provided but instead + a sequence of :math:`p` values is defined. + These integer values do not need to be sorted. + + + + + + + + Place to store dynamic metadata of the instrument to document as close as possible + the state of the instrument during the event, i.e. in between start_time and end_time. + + + diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml index e6a2881e33..d80bfbda1d 100644 --- a/base_classes/NXfabrication.nxdl.xml +++ b/base_classes/NXfabrication.nxdl.xml @@ -1,4 +1,4 @@ - + + + + + + + Number of images in the stack, for stacks the slowest dimension. + + + + + Number of image points along the slow dimension (k equivalent to z). + + + + + Number of image points along the fast dimension (j equivalent to y). + + + + + Number of image points along the fastest dimension (i equivalent to x). + + + + + Base class for reporting a set of images representing specializations of NXdata. + + The most commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. + + Colloquially, an image is understood as a discretized representation of intensity distribution + detected or simulated for some ROI. When discretized with regular Euclidean tilings, the terms + pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal + or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. + For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term + image point is eventually more appropriate when working with such tilings. + + Therefore, all docstrings in this base class refer to points. Points are considered + exact synonyms for pixel and voxel, which are terms used for regular tilings. + + Point coordinates identify the location of the barycenter. + + For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. + Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal + (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. + Different libraries use different representations and encoding of the images. + Details can be found in the respective sections of the typical FFT libraries documentations: + + * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ + * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + * `NFFT by the TU Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations + + Users are strongly advised to inspect carefully which specific conventions their library uses + to enable storing and modifying the implementation of their code such that the serialized + representations as they are detailed here for NeXus match. + + It is often the case that several images are combined using processing. In this case, + the number of images which are combined into collections is not necessarily the same + for each collection. The NXimage base class addresses this logical distinction + through the notation of indices_image and indices_group concepts. + That is indices_image are always counting from offset in increments of one + as each image is its own entity. By contrast, a group may contain no, or several images. + Consequently, indices_group are not required to be contiguous. + + + + Details how NXdata instance were processed from detector readings/raw data. + + + + Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` + instances in this :ref:`NXimage` were loaded during parsing. + + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. + + The group in combination with an added field *context* therein adds context. + + + + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + + + + + + Link or name of an :ref:`NXdetector` instance with which the data were + collected. + + + + + Program used for processing. + + + + + + One-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + Real part of the image intensity per point. + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Two-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Three-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of one-dimensional images. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of two-dimensional images. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of three-dimensional images. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + diff --git a/base_classes/NXinstrument_apm.nxdl.xml b/base_classes/NXinstrument_apm.nxdl.xml new file mode 100644 index 0000000000..cd4bd92a51 --- /dev/null +++ b/base_classes/NXinstrument_apm.nxdl.xml @@ -0,0 +1,388 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time + inside a parent instance of :ref:`NXevent_data_apm`. + + + + + Base class for instrument-related details of a real or simulated + atom probe tomograph or field-ion microscope. + + For collecting data and experiments which are simulations of an atom probe + microscope or a session with such instrument use the :ref:`NXapm` application definition + and the :ref:`NXevent_data_apm` groups it provides. + + This base class implements the concept of :ref:`NXapm` whereby (meta)data are distinguished + whether these typically change during a session, so-called dynamic, or not, so-called static metadata. + This design allows to store e.g. hardware related concepts only once instead of demanding + that each image or spectrum from the session needs to be stored also with the static metadata. + + + + Which type of instrument. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Location of the lab or place where the instrument is installed. Using GEOREF is + preferred. + + + + + Nominal flight path + + The value can be extracted from the CAnalysis.CSpatial.fFlightPath + field of a CamecaRoot ROOT file. + + + + + Device which reduces ToF differences of ions in ToF experiments. + + For atom probe the reflectron can be considered an energy compensation device. + Such a device can be realized technically e.g. with a Poschenrieder lens. + + Consult the following U.S. patents for further details: + + * 3863068 and 6740872 for the reflectron + * 8134119 for the curved reflectron + + + + Was the reflectron used? + + + + + The maximum voltage applied to the reflectron, relative to system ground. + + + + + + A counter electrode of the LEAP 6000 series atom probes. + + + + + + A local electrode guiding the ion flight path. + Also called counter or extraction electrode. + + + + Acceleration voltage + + + + + The type of aperture used when the local_electrode has an aperture or acts as an aperture + in addition to acting as an extraction electrode. + + The local electrode is a component which combines functionalities of :ref:`NXlens_em`, + :ref:`NXaperture`, if not even :ref:`NXdeflector`: + + * "n/a", use when no aperture is present in the experiment + * "conical", conical aperture with a circular hole + * "feedthrough", an aperture where the specimen protrudes through a circular hole + * "custom", a user modified aperture, which is otherwise non-standard + + + + + + + + + + + + Detector for taking raw time-of-flight and ion/hit impact positions data. + + + + 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 when the detector was an MCP. + + The ATO file format is used primarily by the atom probe group of the + GPM in Rouen, France. + + + + + + + + The value can be extracted from the CRunHeader.fMcpEfficiency + field of a CamecaRoot RHIT file. + + + + + The value can be extracted from the CRunHeader.fMeshEfficiency + field of a CamecaRoot RHIT file. + + + + + + + Laser- and/or voltage-pulsing device to trigger ion removal. + + When the base class NXinstrument_apm is used in the NXapm + application definition, the values for the following fields: + + * pulse_frequency + * pulse_fraction + * pulse_voltage + * pulse_number + * standing_voltage + * pulse_energy + * incidence_vector + * pinhole_position + * spot_position + + should be recorded in the order of, and assumed associated, + with the pulse_id in an instance of :ref:`NXevent_data_apm`. + + + + + + Detail whereby ion extraction is triggered methodologically. + + + + + + + + + + Frequency with which the pulser fire(s). + + + + + 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. + + + + + + Pulsed voltage, in laser pulsing mode this field can be omitted. + + + + + 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. Otherwise, the + standing voltage applied to the sample, relative to system ground. + + + + + Group to store details about components that enable laser pulsing strategies. + + When multiple sources are available, these should be named source1, source2; + the LEAP 6000 series instruments have two sources. The majority of instruments + still has one source. In this case the variable part "ID" can be omitted. + Consequently the group should be named "source" when writing instance data. + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing + strategies to trigger ion extraction via exciting and eventual field evaporation + field emission of ion at the specimen surface. + + + + The wavelength of the radiation emitted by the source. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + Average energy of the laser at peak of each pulse. + + + + Path to pulse_id + + + + + + Details about specific positions along the laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the measurement + how the laser beam shines on the specimen, 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 + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + + + + + + + + + The value can be extracted from the CRunHeader.CAnalysis.fSpecimenTemperature + field of a CamecaRoot RHIT file. + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + + + + + + + + + + The value can be extracted from the CRunHeader.CLasHeader.fAnalysisPressure + field of a CamecaRoot RHIT file. + + + + + + + + + + + + Free-text field for additional comments. + + + + + Relevant quantities during a measurement with a LEAP system as were + suggested by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. + + + + Parameter that defines the rules and control loops whereby the pulser and + other components of the instrument are controlled during evaporation. + + + + + Parameter that assure maintenance of a significant yet not too high + ion influx on the detector to avoid detection losses. + + + + diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml index 1cc6c4c5fc..d4c1e2055b 100644 --- a/base_classes/NXlens_em.nxdl.xml +++ b/base_classes/NXlens_em.nxdl.xml @@ -1,4 +1,4 @@ - + + + + Qualitative description of the lens based on the number of pole pieces. + + diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 39e5da3bf8..8686b8890a 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,9 +1,9 @@ - + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to describe a software tool or library. + + + + Given name of the program. Program can be a commercial one a script, + or a library or a library component. + + + + 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/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml new file mode 100644 index 0000000000..ab79f42be8 --- /dev/null +++ b/base_classes/NXpump.nxdl.xml @@ -0,0 +1,68 @@ + + + + + + Device to reduce an atmosphere to a controlled pressure. + + + + Principle type of the pump. + + + + + + + + + + + + + + + The minimum pressure achievable in a chamber after + it has been pumped down for an extended period. + + + + + The material being moved by the pump. + + Pumps intending to create a vacuum should state "vacuum" as the medium, + while pumps having the primary purpose of creating a flow or pressure + of gas should state "gas" as the medium. + + + + + + + + + + + diff --git a/base_classes/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml index e2411b122f..78e0b5490a 100644 --- a/base_classes/NXresolution.nxdl.xml +++ b/base_classes/NXresolution.nxdl.xml @@ -1,4 +1,4 @@ - + + + + Base class to report on the characterization of an area or volume of material. + + This area or volume of material is considered a region-of-interest (ROI). + + This base class should be used when the characterization was achieved by + processing data from experiment or computer simulations into models of + the microstructure of the material and the properties of the material or its + crystal defects within this ROI. Microstructural features is a narrow synonym + for these crystal defects. + + This base class can also be used to store data and metadata of the + representation of the ROI, i.e. its discretization and shape. + + Methods from computational geometry are typically used for + defining a discretization of the area and volume. + + Do not confuse this base class with :ref:`NXregion`. The purpose + of the :ref:`NXregion` base class is to document data access i.e. + I/O pattern on arrays. Therefore, concepts from :ref:`NXregion` operate + in data space rather than in real or simulated real space. + + + diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 3aa87fb025..64e72f055a 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -102,7 +102,7 @@ A list of concepts in an application definition this file describes. This is for partially filling an application definition. If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. + to be valid, if not only the specified concepts/paths are assumed to be valid. diff --git a/base_classes/NXspectrum.nxdl.xml b/base_classes/NXspectrum.nxdl.xml new file mode 100644 index 0000000000..ac42594101 --- /dev/null +++ b/base_classes/NXspectrum.nxdl.xml @@ -0,0 +1,550 @@ + + + + + + + + + Number of spectra in the stack, for stacks the slowest dimension. + + + + + Number of image points along the slower dimension (k equivalent to z). + + + + + Number of image points along the slow dimension (j equivalent to y). + + + + + Number of image points along the fast dimension (i equivalent to x). + + + + + Number of energy bins (always the fastest dimension). + + + + + Base class container for reporting a set of spectra. + + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. + + Use stack for all other tilings. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXspectrum` were loaded during parsing. + + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. + + The group in combination with an added field *context* therein adds context. + + + + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this :ref:`NXspectrum` instance. + + + + + Link or name of an :ref:`NXdetector` instance with which the data were + collected. + + + + + + + One spectrum for a point of a 0d ROI. Also known as spot measurement. + + + + Counts + + + + + + + Counts + + + + + + Energy axis + + + + + + + Energy + + + + + + + One spectrum for each point of a 1d ROI. + + + + Counts + + + + + + + + Counts + + + + + + Point coordinate along the fast dimension + + + + + + + Point coordinate along the fast dimension + + + + + + Energy axis + + + + + + + Energy + + + + + + + One spectrum for each scan point of 2d ROI. + + + + Counts + + + + + + + + + Counts + + + + + + Point coordinate along the slow dimension + + + + + + + Point coordinate along the slow dimension + + + + + + Point coordinate along the fast dimension + + + + + + + Point coordinate along the fast dimension + + + + + + Energy axis + + + + + + + Energy + + + + + + + One spectrum for point of a 3d ROI. + + + + Counts + + + + + + + + + + Counts + + + + + + Point coordinate along the slower dimension + + + + + + + Point coordinate along the slower dimension + + + + + + Point coordinate along the slow dimension + + + + + + + Point coordinate along the slow dimension + + + + + + Point coordinate along the fast dimension + + + + + + + Point coordinate along the fast dimension + + + + + + Energy axis + + + + + + + Energy + + + + + + + Multiple instances of spectrum_0d. + + + + Counts + + + + + + + + Counts + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Energy axis + + + + + + + Energy + + + + + + + Multiple instances of spectrum_2d. + + + + Counts + + + + + + + + + + Counts + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Point coordinate along the slow dimension + + + + + + + Point coordinate along the slow dimension + + + + + + Point coordinate along the fast dimension + + + + + + + Point coordinate along the fast dimension + + + + + + Energy axis + + + + + + + Energy + + + + + + + Multiple instances of spectrum_3d. + + + + Counts + + + + + + + + + + + Counts + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Point coordinate along the slower dimension + + + + + + + Point coordinate along the slower dimension + + + + + + Point coordinate along the slow dimension + + + + + + + Point coordinate along the slow dimension + + + + + + Point coordinate along the fast dimension + + + + + + + Point coordinate along the fast dimension + + + + + + Energy axis + + + + + + + Energy + + + + + diff --git a/base_classes/NXunit_cell.nxdl.xml b/base_classes/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..f09d55aae9 --- /dev/null +++ b/base_classes/NXunit_cell.nxdl.xml @@ -0,0 +1,163 @@ + + + + + + + + Dimensionality of the lattice. + + + + + Base class to describe structural aspects of an arrangement of + atoms or ions including a crystallographic unit cell. + + Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. + + + + Path to a reference frame in which the unit cell is defined + to resolve ambiguity in cases when e.g. a different reference frame + than the NeXus default reference frame (McStas) was chosen. + + + + + Dimensionality of the structure. + + + + + + + + + + Geometry of the unit cell quantified via parameters a, b, and c. + + + + + + + + Geometry of the unit cell quantified individually via parameter a. + + + + + Geometry of the unit cell quantified individually via parameter b. + + + + + Geometry of the unit cell quantified individually via parameter c. + + + + + Geometry of the unit cell quantified via parameters alpha, beta, and gamma. + + + + + + + + Geometry of the unit cell quantified individually via parameter alpha. + + + + + Geometry of the unit cell quantified individually via parameter beta. + + + + + Geometry of the unit cell quantified individually via parameter gamma. + + + + + Crystal system. + + For a crystal system in 2D space monoclinic is an exact synonym for oblique. + For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. + For a crystal system in 2D space tetragonal is an exact synonym for square. + + + + + + + + + + + + + + Laue group using International Table of Crystallography notation. + + + + + + Point group using International Table of Crystallography notation. + + + + + Space group from the International Table of Crystallography notation. + + + + + 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. + + + + + Area of the unit cell if dimensionality is 2. + + + + + Volume of the unit cell if dimensionality is 3. + + + + diff --git a/base_classes/nyaml/NXactuator.yaml b/base_classes/nyaml/NXactuator.yaml index bd9f95be57..e587584af8 100644 --- a/base_classes/nyaml/NXactuator.yaml +++ b/base_classes/nyaml/NXactuator.yaml @@ -45,7 +45,7 @@ NXactuator(NXcomponent): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # dd10bc8a1c83314427ae289d7c80bc4b53ecfb19d36fc046ef47927b5afa8098 -# +# # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of ion candidates. +# +# +# +# +# Maximum number of allowed atoms per ion. +# +# +# +# +# Number of entries +# +# +# +# +# Base class to document the parameters, configuration, and results of a processing for recovering +# the charge state and nuclide composition of an ion from ranging definitions as used in the research +# field of atom probe microscopy. +# +# A ranging definition classically reports only the mass-to-charge-state-ratio interval plus the +# elemental composition, but not necessarily the nuclide that compose the ion. +# +# As the mass-resolving-power in an atom probe instrument is finite and typically lower +# than for cutting edge tandem mass spectrometry it is possible that different combinations of nuclides +# are indistinguishable and thus multiple ions in eventually even different charge states can be valid +# labels for a given mass-to-charge-state-ratio peak. Enumerating the possible combinations +# is a programmatic approach that can help with peak identification. +# +# +# +# Parameters for the algorithm used to recover which combinations of nuclides +# have a mass and charge that matches a set of constraints. +# +# Each parameter in this group is defines one constraint. +# +# +# +# Parameter that defines the elements considered in the combinatorial search. +# The array contains nuclides as many times as their multiplicity and must not be empty. +# Nuclides are encoded using the hashing rule that is defined in by nuclide_hash of :ref:`NXatom`. +# +# Constraining the elements or nuclides instead of providing all nuclides +# reduces the time to perform an exhaustive combinatorial search. +# +# +# +# +# +# +# +# Parameter that defines the interval :math:`[{\frac{m}{q}}_{min}, {\frac{m}{q}}_{max}]` within which +# ions with given mass-to-charge-state-ratio qualify as candidates. +# +# +# +# +# +# +# +# Parameter that defines the minimum half life for how long each nuclide of each +# ion needs to be stable such that the ion qualifies as a candidate. +# +# +# +# +# Parameter that defines the minimum natural abundance of each nuclide of each +# ion such that the ion qualifies as a candidate. +# +# +# +# +# If the value is false, it means that non-unique solutions are accepted. +# These are solutions where multiple candidates have been built from +# different nuclide instances but the charge_state of all the ions is the same. +# +# +# +# +# +# Signed charge, i.e. integer multiple of the elementary +# charge of each candidate. +# +# +# +# +# +# +# +# Table of nuclide instances of which each candidate is composed. +# Each row vector is sorted in descending order. +# Unused entries in the matrix should be set to 0. +# Use the hashing rule that is defined in nuclide_hash of :ref:`NXatom`. +# +# +# +# +# +# +# +# +# Accumulated mass of the nuclides in each candidate. +# Not corrected for quantum effects. +# +# +# +# +# +# +# +# The product of the natural abundances of the nuclides for each candidate. +# +# +# +# +# +# +# +# For each candidate the half life of the nuclide that has the +# shortest half life. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXapm_measurement.yaml b/base_classes/nyaml/NXapm_measurement.yaml new file mode 100644 index 0000000000..11f255a755 --- /dev/null +++ b/base_classes/nyaml/NXapm_measurement.yaml @@ -0,0 +1,113 @@ +category: base +doc: | + Base class for collecting a run with a real or a simulated atom probe or field-ion microscope. + + The term run is understood as an exact synonym for session, i.e. the usage of a real or simulated + tomograph or microscope for a certain amount of time during which one characterizes a single specimen. + + Research workflows for experiments and simulations of atom probe and related field-evaporation + evolve continuously and become increasingly connected with other methods used for material + characterization specifically electron microscopy. A few examples in this direction are: + + * `T. Kelly et al. `_ + * `C. Fleischmann et al. `_ + * `W. Windl et al. `_ + * `C. Freysoldt et al. `_ + * `G. da Costa et al. `_ + + The majority of atom probe research is performed using the so-called Local Electrode Atom Probe (LEAP) instruments + from AMETEK/Cameca. In addition, several research groups have built their own instruments and shared different + aspects of the technical specifications and approaches including how these groups apply data processing e.g.: + + * `M. Monajem et al. `_ + * `P. Stender et al. `_ + * `I. Dimkou et al. `_ + + to name but a few. +type: group +NXapm_measurement(NXobject): + status(NX_CHAR): + doc: | + A statement whether the measurement completed successfully, or was aborted. + enumeration: [success, aborted] + quality(NX_CHAR): + doc: | + Statement about the quality of the measurement. + + The value can be extracted from the CAnalysis.CResults.fQuality + field of a CamecaRoot ROOT file. + (NXinstrument_apm): + (NXevent_data_apm): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 85fa0cb41b085e4263ca6a0ddab3aff086d8648f508d16664b4ed50d3ac4c93e +# +# +# +# +# +# Base class for collecting a run with a real or a simulated atom probe or field-ion microscope. +# +# The term run is understood as an exact synonym for session, i.e. the usage of a real or simulated +# tomograph or microscope for a certain amount of time during which one characterizes a single specimen. +# +# Research workflows for experiments and simulations of atom probe and related field-evaporation +# evolve continuously and become increasingly connected with other methods used for material +# characterization specifically electron microscopy. A few examples in this direction are: +# +# * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ +# * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ +# * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ +# * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ +# * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ +# +# The majority of atom probe research is performed using the so-called Local Electrode Atom Probe (LEAP) instruments +# from AMETEK/Cameca. In addition, several research groups have built their own instruments and shared different +# aspects of the technical specifications and approaches including how these groups apply data processing e.g.: +# +# * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ +# * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ +# * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ +# +# to name but a few. +# +# +# +# A statement whether the measurement completed successfully, or was aborted. +# +# +# +# +# +# +# +# +# Statement about the quality of the measurement. +# +# The value can be extracted from the CAnalysis.CResults.fQuality +# field of a CamecaRoot ROOT file. +# +# +# +# +# diff --git a/base_classes/nyaml/NXapm_ranging.yaml b/base_classes/nyaml/NXapm_ranging.yaml new file mode 100644 index 0000000000..18fd667eef --- /dev/null +++ b/base_classes/nyaml/NXapm_ranging.yaml @@ -0,0 +1,199 @@ +category: base +doc: | + Base class for the configuration and results of ranging definitions. + + Ranging is a data post-processing step used in the research field of + atom probe during which elemental, isotopic, and/or molecular identities + are assigned to mass-to-charge-state ratios within certain intervals. + The documentation of these steps is based on ideas that + have been described in the literature: + + * `M. K. Miller `_ + * `D. Haley et al. `_ + * `M. Kühbach et al. `_ +type: group +NXapm_ranging(NXprocess): + (NXprogram): + (NXnote): + mass_to_charge_distribution(NXprocess): + doc: | + Specifies the mass-to-charge-state ratio histogram. + (NXprogram): + min_mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Smallest :math:`{\frac{m}{q}}_{min}` mass-to-charge-state ratio value. + + The lower (left-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. + max_mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Largest :math:`{\frac{m}{q}}_{max}` mass-to-charge-state ratio value. + + The upper (right-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. + n_mass_to_charge(NX_POSINT): + unit: NX_UNITLESS + doc: | + The number of bins on the interval :math:`[{\frac{m}{q}}_{min}`, + {\frac{m}{q}}_{max}]`. + mass_spectrum(NXdata): + doc: | + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + background_quantification(NXprocess): + doc: | + Details of the background model that was used to + correct the total counts per bin into counts. + (NXprogram): + description(NX_CHAR): + doc: | + Free-text field to describe how atom probers define a background model. + + Thereby, community feedback can be collected to inform an improved + version of this base class in the future. + peak_search_and_deconvolution(NXprocess): + doc: | + How were peaks in the mass-to-charge-state ratio histogram identified. + (NXprogram): + (NXpeak): + peak_identification(NXprocess): + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + (NXprogram): + number_of_ion_types(NX_UINT): + unit: NX_UNITLESS + 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 representing a reserved value. + + Consequently, start counting iontypes from 1. + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + unit: NX_UNITLESS + doc: | + Assumed maximum value that suffices to store all relevant molecular ions, + even the most complicated ones that one can typically observe and distinguish + typically. Currently, a value of 32 is used (see M. Kühbach et al. `_). + (NXatom): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d4359bfc6a6c742eed6c496e3f87022335671b759f6947866bbcc9eda536b579 +# +# +# +# +# +# Base class for the configuration and results of ranging definitions. +# +# Ranging is a data post-processing step used in the research field of +# atom probe during which elemental, isotopic, and/or molecular identities +# are assigned to mass-to-charge-state ratios within certain intervals. +# The documentation of these steps is based on ideas that +# have been 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>`_ +# +# +# +# +# +# Specifies the mass-to-charge-state ratio histogram. +# +# +# +# +# Smallest :math:`{\frac{m}{q}}_{min}` mass-to-charge-state ratio value. +# +# The lower (left-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. +# +# +# +# +# Largest :math:`{\frac{m}{q}}_{max}` mass-to-charge-state ratio value. +# +# The upper (right-hand side) inclusive bound of the interval :math:`[{\frac{m}{q}}_{min}`, {\frac{m}{q}}_{max}]`. +# +# +# +# +# The number of bins on the interval :math:`[{\frac{m}{q}}_{min}`, +# {\frac{m}{q}}_{max}]`. +# +# +# +# +# A default histogram aka mass spectrum of +# the mass-to-charge-state ratio values. +# +# +# +# +# +# Details of the background model that was used to +# correct the total counts per bin into counts. +# +# +# +# +# Free-text field to describe how atom probers define a background model. +# +# Thereby, community feedback can be collected to inform an improved +# version of this base class in the future. +# +# +# +# +# +# How were peaks in the mass-to-charge-state ratio histogram identified. +# +# +# +# +# +# +# Details about how peaks, with taking into account +# error models, were interpreted as ion types or not. +# +# +# +# +# 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 representing a reserved value. +# +# Consequently, start counting iontypes from 1. +# +# +# +# +# Assumed maximum value that suffices to store all relevant molecular ions, +# even the most complicated ones that one can typically observe and distinguish +# typically. Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). +# +# +# +# +# diff --git a/base_classes/nyaml/NXapm_reconstruction.yaml b/base_classes/nyaml/NXapm_reconstruction.yaml new file mode 100644 index 0000000000..3472d6d12c --- /dev/null +++ b/base_classes/nyaml/NXapm_reconstruction.yaml @@ -0,0 +1,487 @@ +category: base +doc: | + Base class for the configuration and results of a reconstruction algorithm. + + Generating a tomographic reconstruction of the specimen uses selected and + 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. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process - the so-called + evaporation_id, which must not be confused with the pulse_id! +type: group +NXapm_reconstruction(NXprocess): + (NXprogram): + (NXnote): + + # config + config(NXparameters): + doc: | + Parameters that configure a reconstruction algorithm which takes + hit data and mass-to-charge-state ratio values to construct a model + of the evaporated specimen. This model is called the reconstructed volume. + Researchers in the field of atom probe call these algorithms reconstruction + protocols. + + Different such protocols exist. Although these are qualitatively similar, + each protocol uses and interprets the parameters slightly differently. + + The majority of reconstructions is performed with the proprietary software + APSuite / IVAS, the source code for the reconstruction protocols that this + software implements in detail is not open but the parameters and their qualitative + effect on the reconstructed volume follows the protocols that are discussed in + the atom probe literature. This group allows to document these parameters in + a standardized manner. + voltage_filter_initial(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Lowest voltage at which an ion that is considered in the reconstructed + volume has been extracted from the specimen. + voltage_filter_final(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Highest voltage at which an ion that is considered in the reconstructed + volume has been extracted from the specimen. + protocol_name(NX_CHAR): + doc: | + Qualitative statement about which reconstruction protocol was used. + + For reconstructions performed with APSuite / IVAS the value "cameca" + should be used. + enumeration: + open_enum: true + items: [bas, geiser, gault, cameca] + primary_element(NX_CHAR): + doc: | + Assumed primary element based on which the reconstruction is calibrated. + + The value can be extracted from the CAnalysis.CSpatial.fPrimaryElement + field of a CamecaRoot ROOT file. + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Assumed detection efficiency + + The value can be extracted from the CAnalysis.CSpatial.fEfficiency + field of a CamecaRoot ROOT file. + flight_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + Nominal flight path + + The value can be extracted from the CAnalysis.CSpatial.fFlightPath + field of a CamecaRoot ROOT file. + evaporation_field(NX_FLOAT): + unit: NX_ANY + doc: | + Assumed evaporation electric field + + The value can be extracted from the CAnalysis.CSpatial.fEvaporationField + field of a CamecaRoot ROOT file. + image_compression(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Image compression factor (ICF) + + The value can be extracted from the CAnalysis.CSpatial.fImageCompression + field of a CamecaRoot ROOT file. + kfactor(NX_FLOAT): + unit: NX_VOLUME + doc: | + Sum of ion volumes + + The value can be extracted from the CAnalysis.CSpatial.fKfactor + field of a CamecaRoot ROOT file. + shank_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Shank angle + + The value can be extracted from the CAnalysis.CSpatial.fShankAngle + field of a CamecaRoot ROOT file. + ion_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Assumed atomic volume + tip_radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + The value can be extracted from the CAnalysis.CSpatial.fTipRadius + field of a CamecaRoot ROOT file. + tip_radius_zero(NX_FLOAT): + unit: NX_LENGTH + doc: | + The value can be extracted from the CAnalysis.CSpatial.fTipRadius0 + field of a CamecaRoot ROOT file. + voltage_zero(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The value can be extracted from the CAnalysis.CSpatial.fVoltage0 + field of a CamecaRoot ROOT file. + crystallographic_calibration(NX_CHAR): + doc: | + Different strategies for crystallographic calibration of the + reconstruction are possible. Therefore, we collect first such + feedback before parametrizing this further. + + If no crystallographic calibration was performed, the field + should be filled with the n/a, meaning not applied. + comment(NX_CHAR): + doc: | + Possibility of a free text field that allows to report additional details related to + the reconstruction protocol. For LEAP systems and reconstructions that are + performed with APSuite / IVAS see also `B. Gault et al. _` + and `T. Blum et al. `_ (page 371). + for best practices on the reporting of metadata in atom probe tomography. + + # results + reconstructed_positions(NX_FLOAT): + unit: NX_LENGTH + doc: | + Three-dimensional positions of the ions in the reconstructed volume. + dimensions: + rank: 2 + dim: (n, 3) + \@depends_on(NX_CHAR): + doc: | + The instance of :ref:`NXcoordinate_system` in which the positions are defined. + + # plots and statistics about the reconstructed volume + naive_discretization(NXprocess): + (NXprogram): + (NXdata): + doc: | + Visual overview of the reconstructed dataset via a three-dimensional + histogram of ion counts. Ion counts are characterized using one nanometer + cubic bins without applying any smoothening of reconstructed positions + during the histogram computation. + + Such preview is useful to get an impression of the macroscopic shape of the + reconstructed volume. Visualizing by ion counts highlights density variations + the reconstructed volume that are signatures of features such as poles, + interfaces or irregularities of the specimen shape. + volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Sum of ion volumes + + The value can be extracted from the CAnalysis.CSpatial.fRecoVolume + field of a CamecaRoot ROOT file. + field_of_view(NX_FLOAT): + unit: NX_LENGTH + + # typically in nm reconstruction space not detector coordinates + doc: | + The nominal diameter of the specimen ROI which is measured in the + experiment. The physical specimen cannot be measured completely + because ions may launch but hit in locations other than the detector. + obb(NXcollection): + doc: | + Tight, axis-aligned bounding box about the point cloud of the reconstruction. + xmin(NX_FLOAT): + unit: NX_LENGTH + doc: | + Minimum coordinate value along the x-direction + xmax(NX_FLOAT): + unit: NX_LENGTH + doc: | + Maximum coordinate value along the x-direction + ymin(NX_FLOAT): + unit: NX_LENGTH + doc: | + Minimum coordinate value along the y-direction + ymax(NX_FLOAT): + unit: NX_LENGTH + doc: | + Maximum coordinate value along the y-direction + zmin(NX_FLOAT): + unit: NX_LENGTH + doc: | + Minimum coordinate value along the z-direction + zmax(NX_FLOAT): + unit: NX_LENGTH + doc: | + Maximum coordinate value along the z-direction + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cb26300799d2708792b9a84040c6b2b80f994eaec0210976a888c5f141df38ff +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# from which an instance of a reconstructed volume has been generated. +# These ions get new identifier assigned in the process - the so-called +# evaporation_id, which must not be confused with the pulse_id! +# +# +# +# +# Base class for the configuration and results of a reconstruction algorithm. +# +# Generating a tomographic reconstruction of the specimen uses selected and +# 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. +# +# +# +# +# +# +# Parameters that configure a reconstruction algorithm which takes +# hit data and mass-to-charge-state ratio values to construct a model +# of the evaporated specimen. This model is called the reconstructed volume. +# Researchers in the field of atom probe call these algorithms reconstruction +# protocols. +# +# Different such protocols exist. Although these are qualitatively similar, +# each protocol uses and interprets the parameters slightly differently. +# +# The majority of reconstructions is performed with the proprietary software +# APSuite / IVAS, the source code for the reconstruction protocols that this +# software implements in detail is not open but the parameters and their qualitative +# effect on the reconstructed volume follows the protocols that are discussed in +# the atom probe literature. This group allows to document these parameters in +# a standardized manner. +# +# +# +# Lowest voltage at which an ion that is considered in the reconstructed +# volume has been extracted from the specimen. +# +# +# +# +# Highest voltage at which an ion that is considered in the reconstructed +# volume has been extracted from the specimen. +# +# +# +# +# Qualitative statement about which reconstruction protocol was used. +# +# For reconstructions performed with APSuite / IVAS the value "cameca" +# should be used. +# +# +# +# +# +# +# +# +# +# +# Assumed primary element based on which the reconstruction is calibrated. +# +# The value can be extracted from the CAnalysis.CSpatial.fPrimaryElement +# field of a CamecaRoot ROOT file. +# +# +# +# +# Assumed detection efficiency +# +# The value can be extracted from the CAnalysis.CSpatial.fEfficiency +# field of a CamecaRoot ROOT file. +# +# +# +# +# Nominal flight path +# +# The value can be extracted from the CAnalysis.CSpatial.fFlightPath +# field of a CamecaRoot ROOT file. +# +# +# +# +# Assumed evaporation electric field +# +# The value can be extracted from the CAnalysis.CSpatial.fEvaporationField +# field of a CamecaRoot ROOT file. +# +# +# +# +# Image compression factor (ICF) +# +# The value can be extracted from the CAnalysis.CSpatial.fImageCompression +# field of a CamecaRoot ROOT file. +# +# +# +# +# Sum of ion volumes +# +# The value can be extracted from the CAnalysis.CSpatial.fKfactor +# field of a CamecaRoot ROOT file. +# +# +# +# +# Shank angle +# +# The value can be extracted from the CAnalysis.CSpatial.fShankAngle +# field of a CamecaRoot ROOT file. +# +# +# +# +# Assumed atomic volume +# +# +# +# +# The value can be extracted from the CAnalysis.CSpatial.fTipRadius +# field of a CamecaRoot ROOT file. +# +# +# +# +# The value can be extracted from the CAnalysis.CSpatial.fTipRadius0 +# field of a CamecaRoot ROOT file. +# +# +# +# +# The value can be extracted from the CAnalysis.CSpatial.fVoltage0 +# field of a CamecaRoot ROOT file. +# +# +# +# +# Different strategies for crystallographic calibration of the +# reconstruction are possible. Therefore, we collect first such +# feedback before parametrizing this further. +# +# If no crystallographic calibration was performed, the field +# should be filled with the n/a, meaning not applied. +# +# +# +# +# Possibility of a free text field that allows to report additional details related to +# the reconstruction protocol. For LEAP systems and reconstructions that are +# performed with APSuite / IVAS see also `B. Gault et al. <https://doi.org/10.1093/mam/ozae081>_` +# and `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# for best practices on the reporting of metadata in atom probe tomography. +# +# +# +# +# +# +# Three-dimensional positions of the ions in the reconstructed volume. +# +# +# +# +# +# +# +# The instance of :ref:`NXcoordinate_system` in which the positions are defined. +# +# +# +# +# +# +# +# +# Visual overview of the reconstructed dataset via a three-dimensional +# histogram of ion counts. Ion counts are characterized using one nanometer +# cubic bins without applying any smoothening of reconstructed positions +# during the histogram computation. +# +# Such preview is useful to get an impression of the macroscopic shape of the +# reconstructed volume. Visualizing by ion counts highlights density variations +# the reconstructed volume that are signatures of features such as poles, +# interfaces or irregularities of the specimen shape. +# +# +# +# +# +# Sum of ion volumes +# +# The value can be extracted from the CAnalysis.CSpatial.fRecoVolume +# field of a CamecaRoot ROOT file. +# +# +# +# +# +# The nominal diameter of the specimen ROI which is measured in the +# experiment. The physical specimen cannot be measured completely +# because ions may launch but hit in locations other than the detector. +# +# +# +# +# Tight, axis-aligned bounding box about the point cloud of the reconstruction. +# +# +# +# Minimum coordinate value along the x-direction +# +# +# +# +# Maximum coordinate value along the x-direction +# +# +# +# +# Minimum coordinate value along the y-direction +# +# +# +# +# Maximum coordinate value along the y-direction +# +# +# +# +# Minimum coordinate value along the z-direction +# +# +# +# +# Maximum coordinate value along the z-direction +# +# +# +# diff --git a/base_classes/nyaml/NXapm_simulation.yaml b/base_classes/nyaml/NXapm_simulation.yaml new file mode 100644 index 0000000000..946c069d7d --- /dev/null +++ b/base_classes/nyaml/NXapm_simulation.yaml @@ -0,0 +1,46 @@ +category: base +doc: | + Base class for simulation of ion extraction from matter via laser and/or voltage + pulsing. +type: group +NXapm_simulation(NXobject): + (NXprogram): + (NXparameters): + (NXprocess): + (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 091fc2ed9cfe2e0bd98015b42569baa6d6db438f4fafa8fd81cae23cafcbe330 +# +# +# +# +# +# Base class for simulation of ion extraction from matter via laser and/or voltage +# pulsing. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXatom.yaml b/base_classes/nyaml/NXatom.yaml new file mode 100644 index 0000000000..ce72b8adf8 --- /dev/null +++ b/base_classes/nyaml/NXatom.yaml @@ -0,0 +1,379 @@ +category: base +doc: | + Base class for documenting a set of atoms. + + Atoms in the set may be bonded. The set may have + a net charge to represent an ion. + An ion can be a molecular ion. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_pos: | + Number of atom positions. + d: | + Dimensionality + n_ivec_max: | + Maximum number of atoms/isotopes allowed per ion. + n_ranges: | + Number of mass-to-charge-state-ratio range intervals for ion type. +type: group +NXatom(NXobject): + name(NX_CHAR): + doc: | + Given name for the set. + + This field could for example be used in the research field + of atom probe tomography to store a standardized human-readable + name of the element or ion like such as Al +++ or 12C +. + id(NX_UINT): + unit: NX_UNITLESS + doc: | + Given numerical identifier for the set. + + The identifier zero is reserved for the special unknown ion type. + identifier_chemical(NX_CHAR): + doc: | + Identifier used to refer to if the set of atoms represents a substance. + enumeration: [inchi] + charge(NX_NUMBER): + unit: NX_CHARGE + doc: | + Signed net (partial) charge of the (molecular) ion. + + Different methods for computing charge are in use. + Care needs to be exercised with respect to the integration. + `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. + charge_state(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Charge reported in multiples of the charge of an electron. + + For research using atom probe tomography the value should be set to + zero if the charge_state is unknown and irrecoverable. This can happen + when classical ranging definition files in formats like RNG, RRNG are used. + These file formats do not document the charge state explicitly but only + the number of atoms of each element per molecular ion surplus the + respective mass-to-charge-state-ratio interval. + + Details on ranging definition files in the literature are `M. K. Miller `_. + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Assumed volume affected by the set of atoms. + + Neither individual atoms nor a set of cluster of these have a volume + that is unique as a some cut-off criterion is required. + indices(NX_CHAR): + doc: | + Index for each atom at locations as detailed by position. + Indices can be used as identifier and thus names for individual atoms. + dimensions: + rank: 1 + dim: (n_pos,) + type(NX_UINT): + unit: NX_UNITLESS + doc: | + Nuclide information for each atom at locations as detailed by position. + + One `approach `_ for storing nuclide information + efficiently is via individual hash values. + Consult the docstring of ``nuclide_hash`` for further details. + dimensions: + rank: 1 + dim: (n_pos,) + position(NX_NUMBER): + unit: NX_ANY + doc: | + Position of each atom. + dimensions: + rank: 2 + dim: (n_pos, d) + \@reference_frame(NX_CHAR): + doc: | + Path to a reference frame in which positions are defined + to resolve ambiguity when the reference frame is different + to the NeXus default reference frame (McStas). + occupancy(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Relative occupancy of the atom position. + + This field is useful for specifying the atomic motif in + instances of :ref:`NXunit_cell`. + dimensions: + rank: 1 + dim: (n_pos,) + nuclide_hash(NX_UINT): + unit: NX_UNITLESS + doc: | + Vector of nuclide hash values. The vector is sorted in decreasing order. + + Individual hash values :math:`H` `encode `_ + for each nuclide or element the number of protons :math:`Z` and a constant :math:`c` + via the following hashing rule :math:`H = Z + c \cdot 256` . :math:`Z and c` must be 8-bit unsigned integers. + + The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. + The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. + + Exemplified for hydrogen (meaning irrespective which isotope), its hash value is :math:`H = 1 + 255 \cdot 256 = 65281`. + Exemplified for the :math:`^{1}H` hydrogen isotope (:math:`Z = 1, N = 0`), its hash value is :math:`H = 1 + 0 \cdot 256 = 1`. + Exemplified for the :math:`^{2}H` deuterium isotope (:math:`Z = 1, N = 1`), its hash value is :math:`H = 1 + 1 \cdot 256 = 257`. + Exemplified for the :math:`^{3}H` tritium isotope (:math:`Z = 1, N = 2`), its hash value is :math:`H = 1 + 2 \cdot 256 = 513`. + Exemplified for the :math:`^{99}Tc` technetium isotope (:math:`Z = 43, N = 56`), its hash value is :math:`H = 43 + 56 \cdot 256 = 14379`. + The special hash value :math:`0` is a placeholder. + + This hashing rule implements a bitshift operation. The benefit is that this enables encoding of all + currently known nuclides and elements efficiently into an 16-bit unsigned integer. Sufficient + unused indices remain to case situations when new elements will be discovered. + dimensions: + rank: 1 + dim: (n_ivec_max,) + nuclide_list(NX_UINT): + unit: NX_UNITLESS + doc: | + Table which decodes the entries in nuclide_hash into a human-readable matrix + instances for either nuclids or elements. Specifically, the first row specifies the + nuclide mass number. When the nuclide_hash values are used this means + the row should report the sum :math:`Z + N` or 0. The value 0 documents that + an element from the IUPAC periodic table is meant. + The second row specifies the number of protons :math:`Z`. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a column vector (14, 6). + The array is stored matching the order of nuclide_hash. + dimensions: + rank: 2 + dim: (n_ivec_max, 2) + mass_to_charge_range(NX_NUMBER): + unit: NX_ANY + doc: | + Associated lower :math:`{\frac{m}{q}}_{min}` and upper :math:`{\frac{m}{q}}_{max}` bounds of the + mass-to-charge-state ratio interval(s) :math:`[{\frac{m}{q}}_{min}, {\frac{m}{q}}_{max}]`. + (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` + steps of indexing a ToF/mass-to-charge-state ratio histogram. + dimensions: + rank: 2 + dim: (n_ranges, 2) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1b11080cf5aae3fd44f2010cbf2e7818a41f9b452dbfcd92396c4ab4fa94ba3d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of atom positions. +# +# +# +# +# Dimensionality +# +# +# +# +# Maximum number of atoms/isotopes allowed per ion. +# +# +# +# +# Number of mass-to-charge-state-ratio range intervals for ion type. +# +# +# +# +# Base class for documenting a set of atoms. +# +# Atoms in the set may be bonded. The set may have +# a net charge to represent an ion. +# An ion can be a molecular ion. +# +# +# +# Given name for the set. +# +# This field could for example be used in the research field +# of atom probe tomography to store a standardized human-readable +# name of the element or ion like such as Al +++ or 12C +. +# +# +# +# +# Given numerical identifier for the set. +# +# The identifier zero is reserved for the special unknown ion type. +# +# +# +# +# Identifier used to refer to if the set of atoms represents a substance. +# +# +# +# +# +# +# +# Signed net (partial) charge of the (molecular) ion. +# +# Different methods for computing charge are in use. +# Care needs to be exercised with respect to the integration. +# `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. +# +# +# +# +# Charge reported in multiples of the charge of an electron. +# +# For research using atom probe tomography the value should be set to +# zero if the charge_state is unknown and irrecoverable. This can happen +# when classical ranging definition files in formats like RNG, RRNG are used. +# These file formats do not document the charge state explicitly but only +# the number of atoms of each element per molecular ion surplus the +# respective mass-to-charge-state-ratio interval. +# +# Details on ranging definition files in the literature are `M. K. Miller <https://doi.org/10.1002/sia.1719>`_. +# +# +# +# +# Assumed volume affected by the set of atoms. +# +# Neither individual atoms nor a set of cluster of these have a volume +# that is unique as a some cut-off criterion is required. +# +# +# +# +# Index for each atom at locations as detailed by position. +# Indices can be used as identifier and thus names for individual atoms. +# +# +# +# +# +# +# +# Nuclide information for each atom at locations as detailed by position. +# +# One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information +# efficiently is via individual hash values. +# Consult the docstring of ``nuclide_hash`` for further details. +# +# +# +# +# +# +# +# Position of each atom. +# +# +# +# +# +# +# +# Path to a reference frame in which positions are defined +# to resolve ambiguity when the reference frame is different +# to the NeXus default reference frame (McStas). +# +# +# +# +# +# Relative occupancy of the atom position. +# +# This field is useful for specifying the atomic motif in +# instances of :ref:`NXunit_cell`. +# +# +# +# +# +# +# +# Vector of nuclide hash values. The vector is sorted in decreasing order. +# +# Individual hash values :math:`H` `encode <https://doi.org/10.1017/S1431927621012241>`_ +# for each nuclide or element the number of protons :math:`Z` and a constant :math:`c` +# via the following hashing rule :math:`H = Z + c \cdot 256` . :math:`Z and c` must be 8-bit unsigned integers. +# +# The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. +# The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. +# +# Exemplified for hydrogen (meaning irrespective which isotope), its hash value is :math:`H = 1 + 255 \cdot 256 = 65281`. +# Exemplified for the :math:`^{1}H` hydrogen isotope (:math:`Z = 1, N = 0`), its hash value is :math:`H = 1 + 0 \cdot 256 = 1`. +# Exemplified for the :math:`^{2}H` deuterium isotope (:math:`Z = 1, N = 1`), its hash value is :math:`H = 1 + 1 \cdot 256 = 257`. +# Exemplified for the :math:`^{3}H` tritium isotope (:math:`Z = 1, N = 2`), its hash value is :math:`H = 1 + 2 \cdot 256 = 513`. +# Exemplified for the :math:`^{99}Tc` technetium isotope (:math:`Z = 43, N = 56`), its hash value is :math:`H = 43 + 56 \cdot 256 = 14379`. +# The special hash value :math:`0` is a placeholder. +# +# This hashing rule implements a bitshift operation. The benefit is that this enables encoding of all +# currently known nuclides and elements efficiently into an 16-bit unsigned integer. Sufficient +# unused indices remain to case situations when new elements will be discovered. +# +# +# +# +# +# +# +# Table which decodes the entries in nuclide_hash into a human-readable matrix +# instances for either nuclids or elements. Specifically, the first row specifies the +# nuclide mass number. When the nuclide_hash values are used this means +# the row should report the sum :math:`Z + N` or 0. The value 0 documents that +# an element from the IUPAC periodic table is meant. +# The second row specifies the number of protons :math:`Z`. +# The value 0 in this case documents a placeholder or that no element-specific +# information is relevant. +# +# Taking a carbon-14 nuclide as an example the mass number is 14. +# That is encoded as a column vector (14, 6). +# The array is stored matching the order of nuclide_hash. +# +# +# +# +# +# +# +# +# Associated lower :math:`{\frac{m}{q}}_{min}` and upper :math:`{\frac{m}{q}}_{max}` bounds of the +# mass-to-charge-state ratio interval(s) :math:`[{\frac{m}{q}}_{min}, {\frac{m}{q}}_{max}]`. +# (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` +# steps of indexing a ToF/mass-to-charge-state ratio histogram. +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXchemical_composition.yaml b/base_classes/nyaml/NXchemical_composition.yaml new file mode 100644 index 0000000000..b2d1882576 --- /dev/null +++ b/base_classes/nyaml/NXchemical_composition.yaml @@ -0,0 +1,153 @@ +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. +type: group +NXchemical_composition(NXobject): + normalization(NX_CHAR): + 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 which are of a particular type. + By contrast, weight_percent normalization factorizes in the + respective mass of the elements. Software libraries that work with + units, like pint in Python, are challenged by these differences as + at.-% and wt.-% are both fractional quantities. + enumeration: [atom_percent, weight_percent] + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total formula mass or number of atoms, depending on the + normalization stated in the normalization field. + dimensions: + rank: 1 + dim: (n,) + ELEMENT(NXatom): + exists: ['min', '1', 'max', 'unbounded'] + nameType: any + doc: | + If this group is used to report the composition of elements from the periodic table, + the group should use the chemical symbol of that element. For other case the + group name is unconstrained. + amount(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total yields the composition + of this element, isotope, molecule, or ion. + dimensions: + rank: 1 + dim: (n,) + composition(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Composition value for the element/ion referred to under name. + Composition is reported either normalized for atomic or weight + percent. The field normalization should be used to communicate + this explicitly. Composition should be reported consistently + for all instances ELEMENT. + composition_errors(NX_FLOAT): + exists: recommended + unit: NX_DIMENSIONLESS + doc: | + Magnitude of the standard deviation of the composition. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1f60c794061e1a994a90b38b39d3f531a5888cca51f6fc7b7b1ee240e25fc307 +# +# +# +# +# +# +# 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. +# +# +# +# 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 which are of a particular type. +# By contrast, weight_percent normalization factorizes in the +# respective mass of the elements. Software libraries that work with +# units, like pint in Python, are challenged by these differences as +# at.-% and wt.-% are both fractional quantities. +# +# +# +# +# +# +# +# +# Total formula mass or number of atoms, depending on the +# normalization stated in the normalization field. +# +# +# +# +# +# +# +# If this group is used to report the composition of elements from the periodic table, +# the group should use the chemical symbol of that element. For other case the +# group name is unconstrained. +# +# +# +# Count or weight which, when divided by total yields the composition +# of this element, isotope, molecule, or ion. +# +# +# +# +# +# +# +# Composition value for the element/ion referred to under name. +# Composition is reported either normalized for atomic or weight +# percent. The field normalization should be used to communicate +# this explicitly. Composition should be reported consistently +# for all instances ELEMENT. +# +# +# +# +# Magnitude of the standard deviation of the composition. +# +# +# +# diff --git a/base_classes/nyaml/NXcircuit.yaml b/base_classes/nyaml/NXcircuit.yaml new file mode 100644 index 0000000000..edf517d056 --- /dev/null +++ b/base_classes/nyaml/NXcircuit.yaml @@ -0,0 +1,255 @@ +category: base +doc: | + Base class for documenting circuit devices. + + Electronic circuits are hardware components that connect several electronic components to achieve + specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. +type: group +NXcircuit(NXcomponent): + hardware(NXfabrication): + doc: | + Hardware where the circuit is implanted; includes information about the + hardware manufacturers and type (e.g. part number) + All the elements below may be single numbers of an array of values with length N_channel + describing multiple input and output channels. + components(NX_CHAR): + doc: | + List of components used in the circuit, e.g., resistors, capacitors, transistors or any + other complex components. + connections(NX_CHAR): + doc: | + Description of how components are interconnected, including connection points + and wiring. + power_source(NX_CHAR): + doc: | + Details of the power source for the circuit, including voltage and current + ratings. + signal_type(NX_CHAR): + doc: | + Type of signal (input signal) the circuit is designed to handle, e.g., analog, + digital, mixed-signal. + + # should this be a min / max range? + operating_frequency(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The operating frequency of the circuit, see also bandwidth, which is possibly + but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth + amplifier at low, audio frequencies 1 - 20,000 Hz). + bandwidth(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The bandwidth of the frequency response of the circuit. + + # we may need an NX_RESISTANCE defined + input_impedance(NX_NUMBER): + unit: NX_ANY + doc: | + Input impedance of the circuit. + output_impedance(NX_NUMBER): + unit: NX_ANY + doc: | + Output impedance of the circuit. + gain(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Gain of the circuit, if applicable, usually all instruments have a gain + which might be important or not. + noise_level(NX_NUMBER): + unit: NX_ANY + doc: | + Root-mean-square (RMS) noise level (in current or voltage) + in the circuit in voltage or current. + temperature_range(NX_NUMBER): + unit: NX_ANY + doc: | + Operating temperature range of the circuit. + calibration(NXcalibration): + doc: | + Calibration data for the circuit. + offset(NX_NUMBER): + unit: NX_ANY + doc: | + Offset value for current or voltage. + output_channels(NX_NUMBER): + doc: | + Number of output channels connected to this circuit. Most probably N_channel. + output_signal(NX_NUMBER): + unit: NX_ANY + doc: | + Type of output signal, e.g., voltage, current, digital. + power_consumption(NX_NUMBER): + unit: NX_ANY + doc: | + Power consumption of the circuit per unit time. + status_indicators(NX_CHAR): + doc: | + Status indicators for the circuit, e.g., LEDs, display readouts. + protection_features(NX_CHAR): + doc: | + Protection features built into the circuit, e.g., overvoltage protection, + thermal shutdown. + acquisition_time(NX_NUMBER): + unit: NX_TIME + doc: | + Updated rate for several processes using the input signal, e.g., History Graph, the circuit + uses for any such process. + output_slew_rate(NX_CHAR): + doc: | + The rate at which the signal changes when ramping from the starting + value. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 715173bc6214e78671570370a926d2f7325a8dda2123015cf0d413147e47b417 +# +# +# +# +# +# Base class for documenting circuit devices. +# +# Electronic circuits are hardware components that connect several electronic components to achieve +# specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. +# +# +# +# Hardware where the circuit is implanted; includes information about the +# hardware manufacturers and type (e.g. part number) +# All the elements below may be single numbers of an array of values with length N_channel +# describing multiple input and output channels. +# +# +# +# +# List of components used in the circuit, e.g., resistors, capacitors, transistors or any +# other complex components. +# +# +# +# +# Description of how components are interconnected, including connection points +# and wiring. +# +# +# +# +# Details of the power source for the circuit, including voltage and current +# ratings. +# +# +# +# +# Type of signal (input signal) the circuit is designed to handle, e.g., analog, +# digital, mixed-signal. +# +# +# +# +# +# The operating frequency of the circuit, see also bandwidth, which is possibly +# but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth +# amplifier at low, audio frequencies 1 - 20,000 Hz). +# +# +# +# +# The bandwidth of the frequency response of the circuit. +# +# +# +# +# +# Input impedance of the circuit. +# +# +# +# +# Output impedance of the circuit. +# +# +# +# +# Gain of the circuit, if applicable, usually all instruments have a gain +# which might be important or not. +# +# +# +# +# Root-mean-square (RMS) noise level (in current or voltage) +# in the circuit in voltage or current. +# +# +# +# +# Operating temperature range of the circuit. +# +# +# +# +# Calibration data for the circuit. +# +# +# +# +# Offset value for current or voltage. +# +# +# +# +# Number of output channels connected to this circuit. Most probably N_channel. +# +# +# +# +# Type of output signal, e.g., voltage, current, digital. +# +# +# +# +# Power consumption of the circuit per unit time. +# +# +# +# +# Status indicators for the circuit, e.g., LEDs, display readouts. +# +# +# +# +# Protection features built into the circuit, e.g., overvoltage protection, +# thermal shutdown. +# +# +# +# +# Updated rate for several processes using the input signal, e.g., History Graph, the circuit +# uses for any such process. +# +# +# +# +# The rate at which the signal changes when ramping from the starting +# value. +# +# +# diff --git a/base_classes/nyaml/NXcomponent.yaml b/base_classes/nyaml/NXcomponent.yaml index 4738bb9813..d2f635284d 100644 --- a/base_classes/nyaml/NXcomponent.yaml +++ b/base_classes/nyaml/NXcomponent.yaml @@ -55,7 +55,7 @@ NXcomponent(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 1e0aeb3958072e69e48c0aaecf3b4867facdf294404855d1568d4eec5ce9e6a7 -# +# # # +# +# +# Base class for reporting the description of a computer +# +# +# +# Given name/alias to the computing system, e.g. MyDesktop. +# +# +# +# +# Name of the operating system, e.g. Windows, Linux, Mac, Android. +# +# +# +# Version plus build number, commit hash, or description of an ever +# persistent resource where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# +# A globally unique persistent identifier of the computer, i.e. +# the Universally Unique Identifier (UUID) of the computing node. +# +# +# +# +# Multiple instances should be named processor1, processor2, etc. +# +# +# +# +# Multiple instances should be named memory1, memory2, etc. +# +# +# +# +# Multiple instances should be named storage1, storage2, etc. +# +# +# diff --git a/base_classes/nyaml/NXcs_filter_boolean_mask.yaml b/base_classes/nyaml/NXcs_filter_boolean_mask.yaml new file mode 100644 index 0000000000..873e3a6f33 --- /dev/null +++ b/base_classes/nyaml/NXcs_filter_boolean_mask.yaml @@ -0,0 +1,136 @@ +category: base +doc: | + Base class for packing and unpacking booleans. + + The field mask should be constructed from packing a vector of booleans + (a bitfield) into unsigned integers with bytesize bitdepth. Padding to + an integer number of such integers is assumed. + + Thereby, this base class can be used to inform software about necessary modulo + operations to decode the mask to recover e.g. set membership of objects in sets + whose membership has been encoded as a vector of booleans. + + This is useful e.g. when processing object sets such as point cloud data. + If e.g. a spatial filter has been applied to a set of points, we may wish to document + memory-space efficiently which points were analyzed. An array of boolean values + is one option to achieve this. A value is true if the point is included and false otherwise. +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. +type: group +NXcs_filter_boolean_mask(NXobject): + depends_on(NX_CHAR): + doc: | + Possibility to refer to which set this mask applies. + + If depends_on is not provided, it is assumed that the mask + applies to its direct parent. + number_of_objects(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of objects represented by the mask. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The content of the mask. If padding is used, + padding bits have to be set to 0. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3995cd8327636f3badc570bb6935642361b70139dac5f3c16b883e21538a5bc8 +# +# +# +# +# +# +# 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. +# +# +# +# +# Base class for packing and unpacking booleans. +# +# The field mask should be constructed from packing a vector of booleans +# (a bitfield) into unsigned integers with bytesize bitdepth. Padding to +# an integer number of such integers is assumed. +# +# Thereby, this base class can be used to inform software about necessary modulo +# operations to decode the mask to recover e.g. set membership of objects in sets +# whose membership has been encoded as a vector of booleans. +# +# This is useful e.g. when processing object sets such as point cloud data. +# If e.g. a spatial filter has been applied to a set of points, we may wish to document +# memory-space efficiently which points were analyzed. An array of boolean values +# is one option to achieve this. A value is true if the point is included and false otherwise. +# +# +# +# Possibility to refer to which set this mask applies. +# +# If depends_on is not provided, it is assumed that the mask +# applies to its direct parent. +# +# +# +# +# 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 content of the mask. If padding is used, +# padding bits have to be set to 0. +# +# +# diff --git a/base_classes/nyaml/NXcs_memory.yaml b/base_classes/nyaml/NXcs_memory.yaml new file mode 100644 index 0000000000..f4ed105c75 --- /dev/null +++ b/base_classes/nyaml/NXcs_memory.yaml @@ -0,0 +1,68 @@ +category: base +doc: | + Base class for reporting the description of the memory system of a computer. +type: group +NXcs_memory(NXcomponent): + (NXcircuit): + doc: | + Typically, computers have multiple instances of memory. + type(NX_CHAR): + doc: | + Qualifier for the type of random access memory. + enumeration: + open_enum: true + items: [ddr4, ddr5] + max_physical_capacity(NX_POSINT): + unit: NX_ANY + doc: | + Total amount of data which the medium can hold. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 02c8be65151092e9de874ee9a8bc407b53c0f3925f193755b7694d4b3e9934a6 +# +# +# +# +# +# Base class for reporting the description of the memory system of a computer. +# +# +# +# Typically, computers have multiple instances of memory. +# +# +# +# Qualifier for the type of random access memory. +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# diff --git a/base_classes/nyaml/NXcs_prng.yaml b/base_classes/nyaml/NXcs_prng.yaml new file mode 100644 index 0000000000..dd10ad12f4 --- /dev/null +++ b/base_classes/nyaml/NXcs_prng.yaml @@ -0,0 +1,134 @@ +category: base +doc: | + Computer science description of pseudo-random number generator. + + The purpose of this base class is to identify if exactly the same sequence can be + reproduced, like for a PRNG or not, like for a true physically random source. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_prng(NXobject): + type(NX_CHAR): + doc: | + Physical approach or algorithm whereby random numbers are generated. + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device whose the state is unpredictable + physically. Some use a strategy of mangling information from the system + clock. Also in this case the sequence is not reproducible without having + additional pieces of information. + + In most cases though so-called pseudo-random number generator (PRNG) + algorithms are used. These yield a deterministic sequence of practically + randomly appearing numbers. These algorithms differ in their quality in + how random the resulting sequences actually are, i.e. sequentially + uncorrelated. Nowadays one of the most commonly used algorithm is the + MersenneTwister (mt19937). + enumeration: [physical, system_clock, mt19937, other] + (NXprogram): + 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. + seed(NX_INT): + unit: NX_UNITLESS + doc: | + Parameter of the PRNG controlling its initialization + and thus controlling the specific sequence generated. + warmup(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of initial draws from the PRNG after its initialized with the seed. + These initial draws are typically discarded in an effort to equilibrate the + sequence. If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + # 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 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 71bcdf7b83514e93216b0edf195944e7a8766346d2d65aac4edd7823439aa944 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of pseudo-random number generator. +# +# The purpose of this base class is to identify if exactly the same sequence can be +# reproduced, like for a PRNG or not, like for a true physically random source. +# +# +# +# Physical approach or algorithm whereby random numbers are generated. +# +# Different approaches for generating random numbers with a computer exists. +# Some use a dedicated physical device whose the state is unpredictable +# physically. Some use a strategy of mangling information from the system +# clock. Also in this case the sequence is not reproducible without having +# additional pieces of information. +# +# In most cases though so-called pseudo-random number generator (PRNG) +# algorithms are used. These yield a deterministic sequence of practically +# randomly appearing numbers. These algorithms differ in their quality in +# how random the resulting sequences actually are, i.e. sequentially +# uncorrelated. 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. +# +# +# +# +# Parameter of the PRNG controlling its initialization +# and thus controlling the specific sequence generated. +# +# +# +# +# Number of initial draws from the PRNG after its initialized with the seed. +# These initial draws are typically discarded in an effort to equilibrate the +# sequence. If no warmup was performed or if warmup procedures are unclear, +# users should set the value to zero. +# +# +# +# diff --git a/base_classes/nyaml/NXcs_processor.yaml b/base_classes/nyaml/NXcs_processor.yaml new file mode 100644 index 0000000000..ec982df747 --- /dev/null +++ b/base_classes/nyaml/NXcs_processor.yaml @@ -0,0 +1,97 @@ +category: base +doc: | + Base class for reporting the description of processing units of a computer. + + Examples are e.g. classical so-called central processing units (CPUs), + coprocessors, graphic cards, accelerator processing units or a system of these. +type: group +NXcs_processor(NXcomponent): + (NXcircuit): + doc: | + Typical examples for the granularization of processing units are: + + * A desktop computer with a single CPU; describe using one instance of NXcircuit. + * A dual-socket server; describe using two instances of NXcircuit. + * A server with two dual-socket server nodes; describe with four + instances of NXcircuit surplus a field that defines their level + in the hierarchy. + type(NX_CHAR): + doc: | + General type of the processing unit e.g. + + * pu, processing core or hyper-threading core + * cpu, (multi-)core central processing unit + * gpu, (multi-)core general purpose processing unit + * fpga, field programmable gate array + enumeration: + open_enum: true + items: [pu, cpu, gpu, fpga] + clock_speed(NX_NUMBER): + doc: | + Clock speed of the circuit + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0c4593244dade75bee8623f85cd3765b001f98d8f35c9f7563f2ad96d615d7b6 +# +# +# +# +# +# Base class for reporting the description of processing units of a computer. +# +# Examples are e.g. classical so-called central processing units (CPUs), +# coprocessors, graphic cards, accelerator processing units or a system of these. +# +# +# +# Typical examples for the granularization of processing units are: +# +# * A desktop computer with a single CPU; describe using one instance of NXcircuit. +# * A dual-socket server; describe using two instances of NXcircuit. +# * A server with two dual-socket server nodes; describe with four +# instances of NXcircuit surplus a field that defines their level +# in the hierarchy. +# +# +# +# General type of the processing unit e.g. +# +# * pu, processing core or hyper-threading core +# * cpu, (multi-)core central processing unit +# * gpu, (multi-)core general purpose processing unit +# * fpga, field programmable gate array +# +# +# +# +# +# +# +# +# +# +# Clock speed of the circuit +# +# +# +# diff --git a/base_classes/nyaml/NXcs_profiling.yaml b/base_classes/nyaml/NXcs_profiling.yaml new file mode 100644 index 0000000000..05e47e8a7c --- /dev/null +++ b/base_classes/nyaml/NXcs_profiling.yaml @@ -0,0 +1,266 @@ +category: base +doc: | + Computer science description for performance and profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + 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 and these are used usually by multiple users. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software i.e. an app took. + A frequent idea is here to answer practical questions like how critical is the + effect on the workflow of the scientists, i.e. is the analysis possible in + a few seconds or would it take days if I were to run this analysis on a + comparable machine? + For this more qualitative performance monitoring, mainly the order of + magnitude is relevant, as well as how this was achieved using parallelization + (i.e. reporting the number of CPU and GPU resources used, the number of + processes and threads configured, and providing basic details about the computer). + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks; in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization, i.e. by software and hardware developers as well as for + tracking bugs. Specialized software exists which documents such performance + data in specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions for now. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + 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. +type: group +NXcs_profiling(NXobject): + + # details about queuing systems etc + current_working_directory(NX_CHAR): + doc: | + Path to the directory from which the tool was called. + 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): + unit: NX_TIME + 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 demands a more precise record of the wall-clock time. + max_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal processes that the app invoked at runtime. + + The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is one. If the app exclusively uses GPU parallelization, number_of_gpus + can be larger than one. If no GPU is used, number_of_gpus is zero, + even though the hardware may have GPUs installed. + max_threads(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal threads that the app invoked at runtime. + Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + max_gpus(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal GPUs that the app invoked at runtime. + + # 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. + (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. + eventID(NXcs_profiling_event): + nameType: partial + 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. + ID is an increasing unsigned integer starting at 1. + + # how to retrieve UUID for cloud computing instances + # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8f7d0b74d0f964836e56f866e550b56f28e0972dc6914ebec8b7dfe37dd5192f +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description for performance and profiling data of an application. +# +# Performance monitoring and benchmarking of software is a task where questions +# can be asked at various levels of detail. In general, there are three main +# 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 and these are used usually by multiple users. +# +# At the most basic level users may wish to document how long e.g. a data +# analysis with a scientific software i.e. an app took. +# A frequent idea is here to answer practical questions like how critical is the +# effect on the workflow of the scientists, i.e. is the analysis possible in +# a few seconds or would it take days if I were to run this analysis on a +# comparable machine? +# For this more qualitative performance monitoring, mainly the order of +# magnitude is relevant, as well as how this was achieved using parallelization +# (i.e. reporting the number of CPU and GPU resources used, the number of +# processes and threads configured, and providing basic details about the computer). +# +# At more advanced levels benchmarks may go as deep as detailed temporal tracking +# of individual processor instructions, their relation to other instructions, the +# state of call stacks; in short eventually the entire app execution history +# and hardware state history. Such analyses are mainly used for performance +# optimization, i.e. by software and hardware developers as well as for +# tracking bugs. Specialized software exists which documents such performance +# data in specifically-formatted event log files or databases. +# +# This base class cannot and should not replace these specific solutions for now. +# Instead, the intention of the base class is to serve scientists at the +# basic level to enable simple monitoring of performance data and log profiling +# data of key algorithmic steps or parts of computational workflows, so that +# these pieces of information can guide users which order of magnitude differences +# 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 demands a more precise record of the wall-clock time. +# +# +# +# +# The number of nominal processes that the app invoked at runtime. +# +# The main idea behind this field e.g. for apps which use e.g. MPI +# (Message Passing Interface) parallelization is to communicate +# how many processes were used. +# +# For sequentially running apps number_of_processes and number_of_threads +# is one. If the app exclusively uses GPU parallelization, number_of_gpus +# can be larger than one. If no GPU is used, number_of_gpus is zero, +# even though the hardware may have GPUs installed. +# +# +# +# +# The number of nominal threads that the app invoked at runtime. +# Specifically here the maximum number of threads used for the +# high-level threading library used (e.g. OMP_NUM_THREADS), posix. +# +# +# +# +# The number of nominal GPUs that the app 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. +# ID is an increasing unsigned integer starting at 1. +# +# +# +# diff --git a/base_classes/nyaml/NXcs_profiling_event.yaml b/base_classes/nyaml/NXcs_profiling_event.yaml new file mode 100644 index 0000000000..33fce1541b --- /dev/null +++ b/base_classes/nyaml/NXcs_profiling_event.yaml @@ -0,0 +1,183 @@ +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. +type: group +NXcs_profiling_event(NXobject): + 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(NX_CHAR): + doc: | + Free-text description what was monitored/executed during the event. + elapsed_time(NX_NUMBER): + unit: NX_TIME + 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 for a more precise record of the + wall-clock time. + + Elapsed time may contain time portions where resources were idling. + max_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal processes that the app invoked during the execution of this event. + + The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is one. If the app exclusively uses GPU parallelization, number_of_gpus + can be larger than one. If no GPU is used, number_of_gpus is zero, + even though the hardware may have GPUs installed. + max_threads(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal threads that the app invoked at during the execution of this event. + Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + max_gpus(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of nominal GPUs that the app invoked during the execution of this + event. + max_virtual_memory_snapshot(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum amount of virtual memory allocated per process during the event. + dimensions: + rank: 1 + dim: (n_processes,) + max_resident_memory_snapshot(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum amount of resident memory allocated per process during the event. + dimensions: + rank: 1 + dim: (n_processes,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 03c76ab650460ab324d251eefa4dfadec0492caba590035735913dfdee451936 +# +# +# +# +# +# +# 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 for a more precise record of the +# wall-clock time. +# +# Elapsed time may contain time portions where resources were idling. +# +# +# +# +# The number of nominal processes that the app invoked during the execution of this event. +# +# The main idea behind this field e.g. for apps which use e.g. MPI +# (Message Passing Interface) parallelization is to communicate +# how many processes were used. +# +# For sequentially running apps number_of_processes and number_of_threads +# is one. If the app exclusively uses GPU parallelization, number_of_gpus +# can be larger than one. If no GPU is used, number_of_gpus is zero, +# even though the hardware may have GPUs installed. +# +# +# +# +# The number of nominal threads that the app invoked at during the execution of this event. +# Specifically here the maximum number of threads used for the +# high-level threading library used (e.g. OMP_NUM_THREADS), posix. +# +# +# +# +# The number of nominal GPUs that the app invoked 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/base_classes/nyaml/NXcs_storage.yaml b/base_classes/nyaml/NXcs_storage.yaml new file mode 100644 index 0000000000..5de9c67642 --- /dev/null +++ b/base_classes/nyaml/NXcs_storage.yaml @@ -0,0 +1,81 @@ +category: base +doc: | + Base class for reporting the description of the I/O of a computer. +type: group +NXcs_storage(NXcomponent): + (NXcircuit): + type(NX_CHAR): + doc: | + Qualifier for the type of storage medium used. + enumeration: [solid_state_disk, hard_disk, optical, tape] + max_physical_capacity(NX_POSINT): + unit: NX_ANY + doc: | + Total amount of data which the medium can hold. + max_read_rate(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum read rate of the storage medium. + max_write_rate(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum write rate of the storage medium. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 41eb1085ca2b20859fa020679ddb4b6f86456c02e37043c212ce77e036b45c26 +# +# +# +# +# +# Base class for reporting the description of the I/O of a computer. +# +# +# +# +# Qualifier for the type of storage medium used. +# +# +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# +# Maximum read rate of the storage medium. +# +# +# +# +# Maximum write rate of the storage medium. +# +# +# +# diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index 0af712aa56..e7517d724d 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -515,7 +515,7 @@ NXdata(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 2aaac78a2fa54b76ecb740cfd6efc667d9c57e9f29428dfb751d195629973972 -# +# # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time. +# +# +# +# +# Base class to store state and (meta)data of events over the course of an atom probe experiment. +# +# Having at least one instance for an instance of NXapm is recommended. +# +# This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs +# of atom probe research. Again static and dynamic quantities are split to avoid a duplication +# of information. Specifically, the time interval considered is the entire time +# starting at start_time until end_time during which we assume the pulser triggered pulses. +# These pulses are identified via the pulse_id field. The point in time when each pulse was +# fired can be recovered from analyzing start_time and delta_time. +# +# Which temporal granularity is adequate depends on the situation and research question. +# Using a model which enables a collection of events offers the most flexible way to cater for +# both atom probe experiments or simulation. To monitor the course of an ion extraction experiment +# (or simulation) it makes sense to track time explicitly via time stamps or implicitly +# via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulse_id. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval started. +# +# If users wish 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, the left bound of the time interval, while +# the end_time specifies the end, the 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. +# +# +# +# +# Delta time array which resolves for each pulse_id the time difference +# between when that pulse was fired and start_time. +# +# In summary, using start_time, end_time, delta_time, pulse_id_offset, +# and pulse_id provides temporal context information when a pulse was +# fired relative to start_time and when it is relevant to translate this into +# coordinated world time UTC. +# +# Note that pulses in reality have a shape and thus additional documentation +# is required to assure that the entries in delta_time are always taken at +# at points in time that, relative to the triggering of the pulse, represent an +# as close as possible state of the pulse. +# +# +# +# +# +# +# +# Integer which defines the first pulse_id. +# Typically, this is either zero or one. +# +# +# +# +# An integer to identify a specific pulse in a sequence. +# +# There are two possibilities to report pulse_id values: +# If pulse_id_offset is provided, the pulse_id values are defined +# by the sequence :math:`[pulse\_id\_offset, pulse\_id\_offset + p]` +# with :math:`p` the number of pulses collected in between +# start_time and end_time. +# +# Alternatively, pulse_id_offset is not provided but instead +# a sequence of :math:`p` values is defined. +# These integer values do not need to be sorted. +# +# +# +# +# +# +# +# Place to store dynamic metadata of the instrument to document as close as possible +# the state of the instrument during the event, i.e. in between start_time and end_time. +# +# +# diff --git a/base_classes/nyaml/NXfabrication.yaml b/base_classes/nyaml/NXfabrication.yaml index 38beefd01e..66519b5986 100644 --- a/base_classes/nyaml/NXfabrication.yaml +++ b/base_classes/nyaml/NXfabrication.yaml @@ -21,14 +21,15 @@ NXfabrication(NXobject): Datetime of component's initial construction. This refers to the date of first measurement after new construction or to the relocation date, if it describes a multicomponent/custom-build setup. - Just the year is often sufficient, but if a full date/time is used, it is recommended to add an explicit time zone. + Just the year is often sufficient, but if a full date/time is used, + it is recommended to add an explicit time zone. capability(NX_CHAR): doc: | Free-text list of functionalities which the component offers. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1840d66dce7f8b21036c35ceba7cc1204cef8bd7835d0927187ea9bdf40a1195 -# +# c4957a2c41923bfaf6302a9472209097b8ed7b18531a54c3558c96bb47b24656 +# # # +# +# +# +# +# +# Number of images in the stack, for stacks the slowest dimension. +# +# +# +# +# Number of image points along the slow dimension (k equivalent to z). +# +# +# +# +# Number of image points along the fast dimension (j equivalent to y). +# +# +# +# +# Number of image points along the fastest dimension (i equivalent to x). +# +# +# +# +# Base class for reporting a set of images representing specializations of NXdata. +# +# The most commonly used scanning methods are supported. That is one-, +# two-, three-dimensional ROIs discretized using regular Euclidean tilings. +# +# Colloquially, an image is understood as a discretized representation of intensity distribution +# detected or simulated for some ROI. When discretized with regular Euclidean tilings, the terms +# pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal +# or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. +# For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term +# image point is eventually more appropriate when working with such tilings. +# +# Therefore, all docstrings in this base class refer to points. Points are considered +# exact synonyms for pixel and voxel, which are terms used for regular tilings. +# +# Point coordinates identify the location of the barycenter. +# +# For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. +# Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal +# (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. +# Different libraries use different representations and encoding of the images. +# Details can be found in the respective sections of the typical FFT libraries documentations: +# +# * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ +# * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ +# * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ +# * `NFFT by the TU Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations +# +# Users are strongly advised to inspect carefully which specific conventions their library uses +# to enable storing and modifying the implementation of their code such that the serialized +# representations as they are detailed here for NeXus match. +# +# It is often the case that several images are combined using processing. In this case, +# the number of images which are combined into collections is not necessarily the same +# for each collection. The NXimage base class addresses this logical distinction +# through the notation of indices_image and indices_group concepts. +# That is indices_image are always counting from offset in increments of one +# as each image is its own entity. By contrast, a group may contain no, or several images. +# Consequently, indices_group are not required to be contiguous. +# +# +# +# Details how NXdata instance were processed from detector readings/raw data. +# +# +# +# Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` +# instances in this :ref:`NXimage` were loaded during parsing. +# +# Possibility to document from which specific other serialized resource as the source +# pieces of information were processed when using NeXus as a semantic file format +# to serialize that information differently. +# +# The group in combination with an added field *context* therein adds context. +# +# +# +# Reference to a location inside the artifact that points to the specific group of values +# that were processed if the artifacts contains several groups of values and thus +# further resolving of ambiguities is required. +# +# +# +# +# +# Link or name of an :ref:`NXdetector` instance with which the data were +# collected. +# +# +# +# +# Program used for processing. +# +# +# +# +# +# One-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Two-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Three-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of one-dimensional images. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of two-dimensional images. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of three-dimensional images. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imag fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# diff --git a/base_classes/nyaml/NXinstrument_apm.yaml b/base_classes/nyaml/NXinstrument_apm.yaml new file mode 100644 index 0000000000..7142835383 --- /dev/null +++ b/base_classes/nyaml/NXinstrument_apm.yaml @@ -0,0 +1,666 @@ +category: base +doc: | + Base class for instrument-related details of a real or simulated + atom probe tomograph or field-ion microscope. + + For collecting data and experiments which are simulations of an atom probe + microscope or a session with such instrument use the :ref:`NXapm` application definition + and the :ref:`NXevent_data_apm` groups it provides. + + This base class implements the concept of :ref:`NXapm` whereby (meta)data are distinguished + whether these typically change during a session, so-called dynamic, or not, so-called static metadata. + This design allows to store e.g. hardware related concepts only once instead of demanding + that each image or spectrum from the session needs to be stored also with the static metadata. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + p: | + Number of pulses collected in between start_time and end_time + inside a parent instance of :ref:`NXevent_data_apm`. + +# One could use an NXnote or reference to another NeXus file where these static (meta)data +# are stored but then referencing this in an application definition would demand to make such +# file required, while NXinstrument_apm can be used directly for the static and the dynamic +# or volatile (meta)data. +type: group +NXinstrument_apm(NXinstrument): + type(NX_CHAR): + doc: | + Which type of instrument. + enumeration: + open_enum: true + items: [Inspico, 3DAP, LAWATAP, LEAP 3000 Si, LEAP 3000X Si, LEAP 3000 HR, LEAP 3000X HR, LEAP 4000 Si, LEAP 4000X Si, LEAP 4000 HR, LEAP 4000X HR, LEAP 5000 XS, LEAP 5000 XR, LEAP 5000 R, EIKOS, EIKOS-UV, LEAP 6000 XR, LEAP INVIZO, Photonic AP, TeraSAT, TAPHR, Modular AP, Titanium APT, Extreme UV APT] + fabrication(NXfabrication): + + # (NXcsg): + location(NX_CHAR): + doc: | + Location of the lab or place where the instrument is installed. Using GEOREF is + preferred. + flight_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + Nominal flight path + + The value can be extracted from the CAnalysis.CSpatial.fFlightPath + field of a CamecaRoot ROOT file. + reflectron(NXcomponent): + doc: | + Device which reduces ToF differences of ions in ToF experiments. + + For atom probe the reflectron can be considered an energy compensation device. + Such a device can be realized technically e.g. with a Poschenrieder lens. + + Consult the following U.S. patents for further details: + + * 3863068 and 6740872 for the reflectron + * 8134119 for the curved reflectron + applied(NX_BOOLEAN): + doc: | + Was the reflectron used? + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The maximum voltage applied to the reflectron, relative to system ground. + decelerate_electrode(NXlens_em): + doc: | + A counter electrode of the LEAP 6000 series atom probes. + + # counter_electrodes being optional WO2016171675A1 or Einzel lens + local_electrode(NXlens_em): + doc: | + A local electrode guiding the ion flight path. + Also called counter or extraction electrode. + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Acceleration voltage + aperture_type(NX_CHAR): + doc: | + The type of aperture used when the local_electrode has an aperture or acts as an aperture + in addition to acting as an extraction electrode. + + The local electrode is a component which combines functionalities of :ref:`NXlens_em`, + :ref:`NXaperture`, if not even :ref:`NXdeflector`: + + * "n/a", use when no aperture is present in the experiment + * "conical", conical aperture with a circular hole + * "feedthrough", an aperture where the specimen protrudes through a circular hole + * "custom", a user modified aperture, which is otherwise non-standard + enumeration: [n/a, conical, feedthrough, custom] + ion_detector(NXdetector): + doc: | + Detector for taking raw time-of-flight and ion/hit impact positions data. + signal_amplitude(NX_FLOAT): + unit: NX_CURRENT + 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 when the detector was an MCP. + + The ATO file format is used primarily by the atom probe group of the + GPM in Rouen, France. + dimensions: + rank: 1 + dim: (p,) + mcp_efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The value can be extracted from the CRunHeader.fMcpEfficiency + field of a CamecaRoot RHIT file. + mesh_efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The value can be extracted from the CRunHeader.fMeshEfficiency + field of a CamecaRoot RHIT file. + + # model, serial_number, manufacturer_name all inherited from NXdetector base class + pulser(NXcomponent): + doc: | + Laser- and/or voltage-pulsing device to trigger ion removal. + + When the base class NXinstrument_apm is used in the NXapm + application definition, the values for the following fields: + + * pulse_frequency + * pulse_fraction + * pulse_voltage + * pulse_number + * standing_voltage + * pulse_energy + * incidence_vector + * pinhole_position + * spot_position + + should be recorded in the order of, and assumed associated, + with the pulse_id in an instance of :ref:`NXevent_data_apm`. + + # technical design + fabrication(NXfabrication): + pulse_mode(NX_CHAR): + doc: | + Detail whereby ion extraction is triggered methodologically. + enumeration: + open_enum: true + items: [laser, voltage, laser_and_voltage] + pulse_frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency with which the pulser fire(s). + pulse_fraction(NX_FLOAT): + unit: NX_DIMENSIONLESS + 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. + + # example of a conditional requirement that can be dealt with rigorously by OWL but not by NeXus! + # as either pulse_voltage is required in an application definition but then that + # existence constraint is independent of other values. + pulse_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Pulsed voltage, in laser pulsing mode this field can be omitted. + pulse_number(NX_UINT): + unit: NX_UNITLESS + doc: | + Absolute number of pulses starting from the beginning of the experiment. + standing_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. Otherwise, the + standing voltage applied to the sample, relative to system ground. + sourceID(NXsource): + nameType: partial + doc: | + Group to store details about components that enable laser pulsing strategies. + + When multiple sources are available, these should be named source1, source2; + the LEAP 6000 series instruments have two sources. The majority of instruments + still has one source. In this case the variable part "ID" can be omitted. + Consequently the group should be named "source" when writing instance data. + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing + strategies to trigger ion extraction via exciting and eventual field evaporation + field emission of ion at the specimen surface. + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The wavelength of the radiation emitted by the source. + power(NX_FLOAT): + unit: NX_POWER + doc: | + Nominal power of the laser source while illuminating the specimen. + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Average energy of the laser at peak of each pulse. + \@logged_against(NX_CHAR): + doc: | + Path to pulse_id + beamID(NXbeam): + nameType: partial + doc: | + Details about specific positions along the laser beam + which illuminates the (atom probe) specimen. + incidence_vector(NX_NUMBER): + unit: NX_LENGTH + doc: | + Track time-dependent settings over the course of the measurement + how the laser beam shines on the specimen, i.e. the mean vector + is parallel to the laser propagation direction. + pinhole_position(NX_NUMBER): + unit: NX_LENGTH + doc: | + Track time-dependent settings over the course of the measurement + where the laser beam exits the focusing optics. + spot_position(NX_NUMBER): + unit: NX_LENGTH + 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. + stage(NXmanipulator): + temperature_sensor(NXsensor): + value(NX_FLOAT): + doc: | + The value can be extracted from the CRunHeader.CAnalysis.fSpecimenTemperature + field of a CamecaRoot RHIT file. + + # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM + analysis_chamber(NXcomponent): + flight_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + pressure_sensor(NXsensor): + measurement(NX_CHAR): + enumeration: [pressure] + value(NX_FLOAT): + unit: NX_PRESSURE + doc: | + The value can be extracted from the CRunHeader.CLasHeader.fAnalysisPressure + field of a CamecaRoot RHIT file. + buffer_chamber(NXcomponent): + load_lock_chamber(NXcomponent): + getter_pump(NXpump): + roughening_pump(NXpump): + turbomolecular_pump(NXpump): + comment(NX_CHAR): + doc: | + Free-text field for additional comments. + control(NXparameters): + doc: | + Relevant quantities during a measurement with a LEAP system as were + suggested by `T. Blum et al. `_. + evaporation_control(NX_CHAR): + doc: | + Parameter that defines the rules and control loops whereby the pulser and + other components of the instrument are controlled during evaporation. + target_detection_rate(NX_NUMBER): + unit: NX_ANY + doc: | + Parameter that assure maintenance of a significant yet not too high + ion influx on the detector to avoid detection losses. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b6183ba0da06e74bcc197f1b73497c25d648d4f7aed36be82e5c2f22f6e4cd26 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time +# inside a parent instance of :ref:`NXevent_data_apm`. +# +# +# +# +# Base class for instrument-related details of a real or simulated +# atom probe tomograph or field-ion microscope. +# +# For collecting data and experiments which are simulations of an atom probe +# microscope or a session with such instrument use the :ref:`NXapm` application definition +# and the :ref:`NXevent_data_apm` groups it provides. +# +# This base class implements the concept of :ref:`NXapm` whereby (meta)data are distinguished +# whether these typically change during a session, so-called dynamic, or not, so-called static metadata. +# This design allows to store e.g. hardware related concepts only once instead of demanding +# that each image or spectrum from the session needs to be stored also with the static metadata. +# +# +# +# Which type of instrument. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Location of the lab or place where the instrument is installed. Using GEOREF is +# preferred. +# +# +# +# +# Nominal flight path +# +# The value can be extracted from the CAnalysis.CSpatial.fFlightPath +# field of a CamecaRoot ROOT file. +# +# +# +# +# Device which reduces ToF differences of ions in ToF experiments. +# +# For atom probe the reflectron can be considered an energy compensation device. +# Such a device can be realized technically e.g. with a Poschenrieder lens. +# +# Consult the following U.S. patents for further details: +# +# * 3863068 and 6740872 for the reflectron +# * 8134119 for the curved reflectron +# +# +# +# Was the reflectron used? +# +# +# +# +# The maximum voltage applied to the reflectron, relative to system ground. +# +# +# +# +# +# A counter electrode of the LEAP 6000 series atom probes. +# +# +# +# +# +# A local electrode guiding the ion flight path. +# Also called counter or extraction electrode. +# +# +# +# Acceleration voltage +# +# +# +# +# The type of aperture used when the local_electrode has an aperture or acts as an aperture +# in addition to acting as an extraction electrode. +# +# The local electrode is a component which combines functionalities of :ref:`NXlens_em`, +# :ref:`NXaperture`, if not even :ref:`NXdeflector`: +# +# * "n/a", use when no aperture is present in the experiment +# * "conical", conical aperture with a circular hole +# * "feedthrough", an aperture where the specimen protrudes through a circular hole +# * "custom", a user modified aperture, which is otherwise non-standard +# +# +# +# +# +# +# +# +# +# +# +# Detector for taking raw time-of-flight and ion/hit impact positions data. +# +# +# +# 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 when the detector was an MCP. +# +# The ATO file format is used primarily by the atom probe group of the +# GPM in Rouen, France. +# +# +# +# +# +# +# +# The value can be extracted from the CRunHeader.fMcpEfficiency +# field of a CamecaRoot RHIT file. +# +# +# +# +# The value can be extracted from the CRunHeader.fMeshEfficiency +# field of a CamecaRoot RHIT file. +# +# +# +# +# +# +# Laser- and/or voltage-pulsing device to trigger ion removal. +# +# When the base class NXinstrument_apm is used in the NXapm +# application definition, the values for the following fields: +# +# * pulse_frequency +# * pulse_fraction +# * pulse_voltage +# * pulse_number +# * standing_voltage +# * pulse_energy +# * incidence_vector +# * pinhole_position +# * spot_position +# +# should be recorded in the order of, and assumed associated, +# with the pulse_id in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Detail whereby ion extraction is triggered methodologically. +# +# +# +# +# +# +# +# +# +# Frequency with which the pulser fire(s). +# +# +# +# +# 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. +# +# +# +# +# +# Pulsed voltage, in laser pulsing mode this field can be omitted. +# +# +# +# +# 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. Otherwise, the +# standing voltage applied to the sample, relative to system ground. +# +# +# +# +# Group to store details about components that enable laser pulsing strategies. +# +# When multiple sources are available, these should be named source1, source2; +# the LEAP 6000 series instruments have two sources. The majority of instruments +# still has one source. In this case the variable part "ID" can be omitted. +# Consequently the group should be named "source" when writing instance data. +# +# Atom probe microscopes use controlled laser, voltage, or a combination of pulsing +# strategies to trigger ion extraction via exciting and eventual field evaporation +# field emission of ion at the specimen surface. +# +# +# +# The wavelength of the radiation emitted by the source. +# +# +# +# +# Nominal power of the laser source while illuminating the specimen. +# +# +# +# +# Average energy of the laser at peak of each pulse. +# +# +# +# Path to pulse_id +# +# +# +# +# +# Details about specific positions along the laser beam +# which illuminates the (atom probe) specimen. +# +# +# +# Track time-dependent settings over the course of the measurement +# how the laser beam shines on the specimen, 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 +# laser focusing optics/pinhole-attached coordinate system is +# defined, how it has to be transformed so that it aligns with +# the specimen coordinate system. +# +# +# +# +# +# +# +# +# The value can be extracted from the CRunHeader.CAnalysis.fSpecimenTemperature +# field of a CamecaRoot RHIT file. +# +# +# +# +# +# +# +# +# The space inside the atom probe along which ions pass nominally +# when they leave the specimen and travel to the detector. +# +# +# +# +# +# +# +# +# +# +# The value can be extracted from the CRunHeader.CLasHeader.fAnalysisPressure +# field of a CamecaRoot RHIT file. +# +# +# +# +# +# +# +# +# +# +# +# Free-text field for additional comments. +# +# +# +# +# Relevant quantities during a measurement with a LEAP system as were +# suggested by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. +# +# +# +# Parameter that defines the rules and control loops whereby the pulser and +# other components of the instrument are controlled during evaporation. +# +# +# +# +# Parameter that assure maintenance of a significant yet not too high +# ion influx on the detector to avoid detection losses. +# +# +# +# diff --git a/base_classes/nyaml/NXlens_em.yaml b/base_classes/nyaml/NXlens_em.yaml index a28ed94e2b..712c7c01c6 100644 --- a/base_classes/nyaml/NXlens_em.yaml +++ b/base_classes/nyaml/NXlens_em.yaml @@ -73,10 +73,14 @@ NXlens_em(NXcomponent): doc: | Qualitative type of lens with respect to the number of pole pieces. enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] + number_of_poles(NX_UINT): + unit: NX_UNITLESS + doc: | + Qualitative description of the lens based on the number of pole pieces. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da0d34149a5d7ee0128593d6cb32345907b6d2d1a556af5dc1c7be7018c7017e -# +# d638ffbb7cda7a9cdc813abe25885bf70722f61be119f8acac32bc9ca9d7d5b9 +# # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Base class to describe a software tool or library. +# +# +# +# Given name of the program. Program can be a commercial one a script, +# or a library or a library component. +# +# +# +# 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/base_classes/nyaml/NXpump.yaml b/base_classes/nyaml/NXpump.yaml new file mode 100644 index 0000000000..44969131bd --- /dev/null +++ b/base_classes/nyaml/NXpump.yaml @@ -0,0 +1,99 @@ +category: base +doc: | + Device to reduce an atmosphere to a controlled pressure. +type: group +NXpump(NXcomponent): + design(NX_CHAR): + doc: | + Principle type of the pump. + enumeration: + open_enum: true + items: [membrane, rotary_vane, roots, turbo_molecular, ion, cryo, diffusion, scroll] + base_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + The minimum pressure achievable in a chamber after + it has been pumped down for an extended period. + medium(NX_CHAR): + doc: | + The material being moved by the pump. + + Pumps intending to create a vacuum should state "vacuum" as the medium, + while pumps having the primary purpose of creating a flow or pressure + of gas should state "gas" as the medium. + enumeration: [vacuum, liquid, gas, slurry, powder] + + # 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 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ce5f2982398390940f305a6ae18a0f5688ea0281f47587d5ba79151460a0d8a4 +# +# +# +# +# +# Device to reduce an atmosphere to a controlled pressure. +# +# +# +# Principle type of the pump. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The minimum pressure achievable in a chamber after +# it has been pumped down for an extended period. +# +# +# +# +# The material being moved by the pump. +# +# Pumps intending to create a vacuum should state "vacuum" as the medium, +# while pumps having the primary purpose of creating a flow or pressure +# of gas should state "gas" as the medium. +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXresolution.yaml b/base_classes/nyaml/NXresolution.yaml index e7a28d4ae6..a2dc0e16db 100644 --- a/base_classes/nyaml/NXresolution.yaml +++ b/base_classes/nyaml/NXresolution.yaml @@ -57,7 +57,7 @@ NXresolution(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # a8a53adb80c6122d2d1de91a1637430ec6543e9c45319c8edbe931573655e233 -# +# # # +# +# +# Base class to report on the characterization of an area or volume of material. +# +# This area or volume of material is considered a region-of-interest (ROI). +# +# This base class should be used when the characterization was achieved by +# processing data from experiment or computer simulations into models of +# the microstructure of the material and the properties of the material or its +# crystal defects within this ROI. Microstructural features is a narrow synonym +# for these crystal defects. +# +# This base class can also be used to store data and metadata of the +# representation of the ROI, i.e. its discretization and shape. +# +# Methods from computational geometry are typically used for +# defining a discretization of the area and volume. +# +# Do not confuse this base class with :ref:`NXregion`. The purpose +# of the :ref:`NXregion` base class is to document data access i.e. +# I/O pattern on arrays. Therefore, concepts from :ref:`NXregion` operate +# in data space rather than in real or simulated real space. +# +# +# diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index 0dc93b3044..a554d1857b 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -205,7 +205,7 @@ NXroot: # A list of concepts in an application definition this file describes. # This is for partially filling an application definition. # If this attribute is not present the application definition is assumed -# to be valid, if not only the specified concepts/paths are assumed to be valid. +# to be valid, if not only the specified concepts/paths are assumed to be valid. # # # diff --git a/base_classes/nyaml/NXspectrum.yaml b/base_classes/nyaml/NXspectrum.yaml new file mode 100644 index 0000000000..78515456a4 --- /dev/null +++ b/base_classes/nyaml/NXspectrum.yaml @@ -0,0 +1,934 @@ +category: base +doc: | + Base class container for reporting a set of spectra. + + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. + + Use stack for all other tilings. + +# set of frequently made specializations of NXdata instances for spectra +symbols: + n_spc: | + Number of spectra in the stack, for stacks the slowest dimension. + n_k: | + Number of image points along the slower dimension (k equivalent to z). + n_j: | + Number of image points along the slow dimension (j equivalent to y). + n_i: | + Number of image points along the fast dimension (i equivalent to x). + n_energy: | + Number of energy bins (always the fastest dimension). +type: group +NXspectrum(NXobject): + (NXprocess): + doc: | + Details how spectra were processed from the detector readings. + input(NXnote): + doc: | + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXspectrum` were loaded during parsing. + + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. + + The group in combination with an added field *context* therein adds context. + context(NX_CHAR): + doc: | + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + mode(NX_CHAR): + doc: | + Imaging (data collection) mode of the instrument during acquisition + of the data in this :ref:`NXspectrum` instance. + detector_identifier(NX_CHAR): + doc: | + Link or name of an :ref:`NXdetector` instance with which the data were + collected. + (NXprogram): + spectrum_0d(NXdata): + doc: | + One spectrum for a point of a 0d ROI. Also known as spot measurement. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Counts + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + spectrum_1d(NXdata): + doc: | + One spectrum for each point of a 1d ROI. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 2 + dim: (n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + axis_i(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the fast dimension + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + spectrum_2d(NXdata): + doc: | + One spectrum for each scan point of 2d ROI. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 3 + dim: (n_j, n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + axis_j(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slow dimension + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension + axis_i(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the fast dimension + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + spectrum_3d(NXdata): + doc: | + One spectrum for point of a 3d ROI. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 4 + dim: (n_k, n_j, n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + axis_k(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slower dimension + dimensions: + rank: 1 + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slower dimension + axis_j(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slow dimension + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension + axis_i(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the fast dimension + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + stack_0d(NXdata): + doc: | + Multiple instances of spectrum_0d. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 2 + dim: (n_spc, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + indices_group(NX_INT): + unit: NX_UNITLESS + doc: | + Group identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + indices_spectrum(NX_INT): + unit: NX_UNITLESS + doc: | + Spectrum identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + stack_2d(NXdata): + doc: | + Multiple instances of spectrum_2d. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 4 + dim: (n_spc, n_j, n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + indices_group(NX_INT): + unit: NX_UNITLESS + doc: | + Group identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + indices_spectrum(NX_INT): + unit: NX_UNITLESS + doc: | + Spectrum identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_j(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slow dimension + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension + axis_i(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the fast dimension + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + stack_3d(NXdata): + doc: | + Multiple instances of spectrum_3d. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts + dimensions: + rank: 5 + dim: (n_spc, n_k, n_j, n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + indices_group(NX_INT): + unit: NX_UNITLESS + doc: | + Group identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + indices_spectrum(NX_INT): + unit: NX_UNITLESS + doc: | + Spectrum identifier + dimensions: + rank: 1 + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_k(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slower dimension + dimensions: + rank: 1 + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slower dimension + axis_j(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the slow dimension + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension + axis_i(NX_NUMBER): + unit: NX_LENGTH + doc: | + Point coordinate along the fast dimension + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 68227c894efa4e970e8826facd84d2676cd89a1a8de369b7af5df2856417c3e6 +# +# +# +# +# +# +# +# +# Number of spectra in the stack, for stacks the slowest dimension. +# +# +# +# +# Number of image points along the slower dimension (k equivalent to z). +# +# +# +# +# Number of image points along the slow dimension (j equivalent to y). +# +# +# +# +# Number of image points along the fast dimension (i equivalent to x). +# +# +# +# +# Number of energy bins (always the fastest dimension). +# +# +# +# +# Base class container for reporting a set of spectra. +# +# The mostly commonly used scanning methods are supported. That is one-, +# two-, three-dimensional ROIs discretized using regular Euclidean tilings. +# +# Use stack for all other tilings. +# +# +# +# Details how spectra were processed from the detector readings. +# +# +# +# Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` +# instances in this :ref:`NXspectrum` were loaded during parsing. +# +# Possibility to document from which specific other serialized resource as the source +# pieces of information were processed when using NeXus as a semantic file format +# to serialize that information differently. +# +# The group in combination with an added field *context* therein adds context. +# +# +# +# Reference to a location inside the artifact that points to the specific group of values +# that were processed if the artifacts contains several groups of values and thus +# further resolving of ambiguities is required. +# +# +# +# +# +# Imaging (data collection) mode of the instrument during acquisition +# of the data in this :ref:`NXspectrum` instance. +# +# +# +# +# Link or name of an :ref:`NXdetector` instance with which the data were +# collected. +# +# +# +# +# +# +# One spectrum for a point of a 0d ROI. Also known as spot measurement. +# +# +# +# Counts +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for each point of a 1d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for each scan point of 2d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for point of a 3d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the slower dimension +# +# +# +# +# +# +# Point coordinate along the slower dimension +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Multiple instances of spectrum_0d. +# +# +# +# Counts +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Multiple instances of spectrum_2d. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Multiple instances of spectrum_3d. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Point coordinate along the slower dimension +# +# +# +# +# +# +# Point coordinate along the slower dimension +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# +# Point coordinate along the slow dimension +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# diff --git a/base_classes/nyaml/NXunit_cell.yaml b/base_classes/nyaml/NXunit_cell.yaml new file mode 100644 index 0000000000..4fd264906e --- /dev/null +++ b/base_classes/nyaml/NXunit_cell.yaml @@ -0,0 +1,265 @@ +category: base +doc: | + Base class to describe structural aspects of an arrangement of + atoms or ions including a crystallographic unit cell. + + Following recommendations of `CIF `_ and `International Tables of Crystallography `_. +symbols: + d: | + Dimensionality of the lattice. +type: group +NXunit_cell(NXobject): + reference_frame(NX_CHAR): + doc: | + Path to a reference frame in which the unit cell is defined + to resolve ambiguity in cases when e.g. a different reference frame + than the NeXus default reference frame (McStas) was chosen. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the structure. + enumeration: [1, 2, 3] + a_b_c(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified via parameters a, b, and c. + dimensions: + rank: 1 + dim: (d,) + a(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter a. + b(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter b. + c(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometry of the unit cell quantified individually via parameter c. + alpha_beta_gamma(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified via parameters alpha, beta, and gamma. + dimensions: + rank: 1 + dim: (d,) + alpha(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter alpha. + beta(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter beta. + gamma(NX_NUMBER): + unit: NX_ANGLE + doc: | + Geometry of the unit cell quantified individually via parameter gamma. + crystal_system(NX_CHAR): + doc: | + Crystal system. + + For a crystal system in 2D space monoclinic is an exact synonym for oblique. + For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. + For a crystal system in 2D space tetragonal is an exact synonym for square. + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography notation. + + # add enumeration of all possible ones here to create a closed enum? + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography notation. + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography notation. + 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. + area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of the unit cell if dimensionality is 2. + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Volume of the unit cell if dimensionality is 3. + (NXatom): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 943076968a4dd669b39f03a88e7b9e7e7af13791a6db68f31519a98de9943469 +# +# +# +# +# +# +# +# Dimensionality of the lattice. +# +# +# +# +# Base class to describe structural aspects of an arrangement of +# atoms or ions including a crystallographic unit cell. +# +# Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. +# +# +# +# Path to a reference frame in which the unit cell is defined +# to resolve ambiguity in cases when e.g. a different reference frame +# than the NeXus default reference frame (McStas) was chosen. +# +# +# +# +# Dimensionality of the structure. +# +# +# +# +# +# +# +# +# +# Geometry of the unit cell quantified via parameters a, b, and c. +# +# +# +# +# +# +# +# Geometry of the unit cell quantified individually via parameter a. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter b. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter c. +# +# +# +# +# Geometry of the unit cell quantified via parameters alpha, beta, and gamma. +# +# +# +# +# +# +# +# Geometry of the unit cell quantified individually via parameter alpha. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter beta. +# +# +# +# +# Geometry of the unit cell quantified individually via parameter gamma. +# +# +# +# +# Crystal system. +# +# For a crystal system in 2D space monoclinic is an exact synonym for oblique. +# For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. +# For a crystal system in 2D space tetragonal is an exact synonym for square. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Laue group using International Table of Crystallography notation. +# +# +# +# +# +# Point group using International Table of Crystallography notation. +# +# +# +# +# Space group from the International Table of Crystallography notation. +# +# +# +# +# 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. +# +# +# +# +# Area of the unit cell if dimensionality is 2. +# +# +# +# +# Volume of the unit cell if dimensionality is 3. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml index a5b6080142..078efbb0e1 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -168,7 +168,7 @@ NXcg_face_list_data_structure(NXcg_primitive): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 0c3df1a1a9726e2c06714aa526c35a2f5ac3da333275277f7ab65f85e663b105 -# +# # # + + + Application definition for normalized representation of electron microscopy research. + + This application definition is a comprehensive, general description for the + standardization of data and metadata collected using electron microscopy. + + NXem is designed to be used for documenting experiments or computer simulations in which + controlled electron beams are used to study electron-beam matter interactions, to simulate this, + to explore physical mechanisms and phenomena, or to characterize materials. + + *The NeXus application definition NXem defines a hierarchical data model with ten building blocks:* + + The data model represents a tree of concepts. The tree is constructed from groups of concepts + representing the branches surplus fields and attributes representing leafs. + + *NXem an introduction for typical use cases in material characterization and simulation:* + + Transmission electron microscopy (TEM) and Scanning Transmission Electron Microscopy (STEM) + Scanning Electron Microscopy (SEM) + Scanning Electron Microscopy combined a Focused-Ion Beam (SEM/FIB) + + *A deeper dive into the branches of NXem:* + + NXem is constructed from composing and specializing base classes into the following ten categories: + + - The field ``definition`` specifies that the data schema is NXem. In combination with + administrative metadata such as the ``NeXus_version`` provided by :ref:`NXroot` this + specifies which version of NXem the instance data in a NeXus/HDF5 file are compliant with. + - The fields ``identifier_experiment``, ``experiment_alias``, ``experiment_description`` and + the group ``userID`` provide concepts for storing organizational metadata that + contextualize the work within the research workflow and humans involved in this. + - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. + - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations + that are associated with or notes, i.e. other artifacts that are deemed relevant when reporting about a measurement + or simulation. These groups are useful when NXem is used as a serialization format for technology-partner-agnostic + archival of data and metadata that have been collected during a session with an electron microscope or when a + simulation was performed. + - The group ``sampleID`` provides concepts for storing metadata about the sample that was + characterized or simulated during the session. + - The group ``measurement`` provides concepts that are useful for describing a measurement + during a session with an electron microscope. This includes the chain of events of data and metadata that + were collected during such a session. + - The group``simulation`` provides concepts that are useful for describing a simulation of an + electron beam that interacts with matter. Combined with ``measurement`` this provides a data schema + for defining a digital twin of the microscope and its optical setup. + - The groups ``consistent_rotations``, ``NAMED_reference_frame`` provide concepts for + reporting coordinate systems (frames of reference) and rotation conventions that clarify how data + should be interpreted specifying the rotation of orientable objects in the microscope, its components, + or of crystals and crystal defects in the material analyzed. These metadata support interpretation for + downstream or on-the-fly data analyses which electron microscopes typically nowadays perform + during a session. Examples are the indexing of diffraction patterns, image analysis in general, or + analyses of the chemical composition. + - The group ``roiID`` provides concepts for reporting several domain- and technique-specific + configuration parameter and results of data processing steps that were applied. + - The group ``profiling`` provides concepts for reporting computational details such as + programs and libraries used, for documenting the libraries of virtual environments such as those used + by conda or python virtual environment, including details about the computing hardware used, and + documenting capabilities for performance analyses and benchmarking of the software or its parts. + + *Design choices:* + + Specific details about how an electron microscope was used and eventually its configuration modified differ + between user groups. This holds also true for computer simulations of electron-beam matter interaction. + Different peer groups in different sub-domains in electron microscopy consider different data and metadata + relevant. NXem defines constraints on the existence and cardinality of concepts and its concept branches + but seeks to offer a compromise. The key design pattern followed is that most branches are made optional + or at most recommended but their child concepts conditional required. Thereby, NXem can cover a variety + of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design + is the combination of the optional group ``measurement`` with its required child + ``measurement/instrument``: Users which report simulations are not forced to document the instrument + but users which have characterized a sample are motivated to report about the instrument. They are though not + necessarily required to report all the details of the instruments' components because the design pattern is-used + applied recursively. + + *Inclusive design, one schema for scanning, focused-ion beam, and transmission electron microscopes:* + + Contrary to many other proposals of a data schema for electron microscopy, NXem seeks to highlight the similarity + of the three fundamental types of electron microscopes that are nowadays used most routinely in academia and + industry: An electron microscope is a beamline that provides a controlled beam of electrons combined with eventually + beams of other particles (ions) to investigate electron/ion(-beam) matter interaction. + This design of per-particle-type concept branches is realized in the base classes ``NXebeam_column`` and ``NXibeam_column``. + These provide concepts for reporting the technical components that are typically used for generating a controllable + (and typically scanning) beam of particles such as electrons or ions. + + Focused-ion beam capabilities are modelled by adding an optional group ``measurement/instrument/ibeam_column``. + We foresee that this design is beneficial also in the future when research should be documented where photon-electron + interactions via an electron microscope are combined. The current proposal though does not include such a + ``NXpbeam_column`` base class that could be used for photon-/light-beam, i.e. laser plus optical + beam path descriptions and components. + + We acknowledge that scanning and transmission electron microscopes are different types of instruments that have distinct differences + in the electron-optical setup and the components used. What remains the same from the perspective of an observer who monitors the + experiment inside the electron-matter interaction volume, i.e. in, on, or close to the surface of the specimen is the imaginary split + into an upper and a lower half-space. In the upper half-space a specific but eventually differently shaped electron beam illuminates + the specimen when comparing a scanning with a transmission electron microscope. In the lower half-space the beam or particles exit + the specimen or end up thermalized in thick specimens. + + *NXem distinguishes and stores instance data based on how long they remain unchanged:* + + ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. + The first group is designed for storing metadata about the instrument which do not change over the course of the session. Examples are + the name of the technology partner who built the microscope, the microscope's serial number, or the type of lenses mounted, etc. + The second group is designed for metadata and data that are collected during the microscope session. For these, specializations of + ``NXdata`` specifically ``NXimage`` and ``NXspectrum`` are provided. Each ``measurement/eventID`` event can be time-stamped + individually. Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose + is to store those specific state and settings of the microscope that was present during the collection of the event. + This includes lens settings, apertures used, aberrations, and other components, etc. + By virtue of design this reduces unnecessary repetition of metadata stored in the first group like is often observed + in image-based archival formats like TIFF, PNG, etc. + + *NXem offers domain-specific classes for standardized reporting of method-specific configurations, data processing, and results:* + + These include ``NXem_img`` for generic and specific imaging including diffraction, ``NXem_eds`` for energy-dispersive X-ray spectroscopy, + ``NXem_ebsd`` for electron backscatter diffraction, as well as ``NXem_eels`` for electron energy loss spectroscopy. These branches provide + examples that proof how NeXus can be used for combining session-centric data storage with data processing. These examples are naturally + incomplete but show at different levels of technical depth and breath how standardization can be useful even to report specifically formatted + data representations like multi-dimensional plotting. Thereby, downstream processing using software for data analyses or research data + management can take advantage of a standardized reporting rather than demanding for a zoo of parsers that interconvert + between many representations. + + *NXem within the ecosystem of data schemata for electron microscopy:** + + We support the statement that substantially fewer standardized rather than many ad hoc schemata are required to facilitate the + documentation and exchange of knowledge within electron microscopy. We tailored NXem to serve the materials science and + materials engineering usage of electron microscopy to provide a complementary coverage to what OMERO has established for + the bio- and life science usage of electron microscopy. + + + + + + + + + + The configuration of the software that was used to generate this NeXus file. + + + + A collection of all programs and libraries used to generate this NeXus file. + Ideally, this would enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific set + of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + Instances can also be used to document the modules and libraries that + are offered by the computational environment such as those parsed + from conda or python virtualenv environments. + + + + + + + + + A (globally) unique persistent identifier for referring to this experiment. + + + + + Alias (short name) which scientists can use to refer to this experiment. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into the 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 - use this start_time field. + + Often though it is useful to specify a time interval via setting both a start_time + and an end_time because this enables software tools and users to collect a + more detailed bookkeeping of the experiment. + + Users should be aware though that even using only start_time and end_time + may not be sufficient to infer how long the experiment took or for how long + data were acquired. To bookkeep more fine-grained timestamps over the + course of the experiment is possible with start_time and end_time fields + of respective :ref:`NXevent_data_em` instances. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + See docstring of the start_time field to see how to use the + start_time and end_time together. + + + + + + Collection of serialized resources associated with the experiment. + Examples of such resources are files which are formatted using proprietary + data models of technology partners as those generated by the control software + of the microscope during the instrument session. + + + + + + + + + Information about persons who performed or were involved in the microscope + session or simulation run. + + + + + + + Given (first) name and surname. + + + + + Name of the affiliation at the point in time when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address at the point in time when the experiment was performed. + + Writing the most permanently used email is recommended. + + + + + Telephone number at the point in time when the experiment was performed. + + + + + User role at the point in time when the experiment was performed. + + Examples are technician operating the microscope, student, postdoc, + principle investigator, or guest. + + + + + + A physical entity which contains material intended to be investigated. + Sample and specimen are treated as de facto synonyms. + Samples can be real or virtual ones as annotated via is_simulation. + + The suggested best practice is to call this group sample. In those cases when + multiple samples need to be grouped inside one entry, these SAMPLE groups + should be named using the prefix sample followed an index starting from 1, i.e. + (sample1, sample2). + + There are at least two strategies how to store (meta)data when one analyzes multiple + samples - not different ROIs on a single sample though - in one session. + + One strategy is to store each sample and its results under an own NXem/ENTRY. + This is one of the most frequent use cases as during most sessions typically only a + single sample is investigated. In this case the name of this group should be sample. + + If multiple samples are investigated storing each of them in their own ENTRY group eventually will + demand unnecessary duplication of instrument details. + + This can be avoided by using another strategy for storing samples and their results. + Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, + like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., + i.e. instances should use sample as a name prefix. + + In this case the collection of events should use identifier_sample to state clearly for which + of the samples loaded the (characterization) event was detected. + + This concept is related to term `Specimen`_ of the EMglossary standard. + + .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 + + + + Qualifier whether the sample is a real (in which case is_simulation should be set to false) + or a virtual one (in which case is_simulation should be set to true). + + + + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes this sample from all others + and especially the predecessor/origin from where that sample was cut off. An example of cutting off + is a steel sheet that is the parent sample from which a small portion was wire-eroded that + represents the sample that was then prepared for characterization with an electron microscope. + + The terms sample and specimen are here considered as exact synonyms. + + This field must not be used for an alias for the sample name. Instead, use name. + + In cases where multiple specimens were loaded into the microscope, the identifier has to resolve + the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single + NXentry should be used for the characterization of a single specimen. + + Details about the specimen preparation should be stored in resources referring to identifier_parent. + + + + + + Identifier of the sample from which the sample was cut off or the string *None*. + I.e. the parent to this sample. + + The purpose of this field is to support functionalities for tracking + sample provenance in a research data management system. + + + + + + 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 timestamp when + the measured specimen surface was actively prepared. Ideally, this matches + the last timestamp that is mentioned in the digital resource pointed to by + identifier_parent. + + Knowing when the specimen was exposed to e.g. specific atmosphere is especially + required for material that is sensitive to the environment such as specimens that were + charged with fast diffusing elements or short-lived radioactive tracers. + + Additional time stamps prior to preparation_date are better placed in resources which + describe but do not pollute the description here with prose. Resolving these + connected metadata is considered the responsibility of the research data management + system and not the a NeXus file. + + + + + Specimen name + + + + + 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 research data management systems an opportunity + to parse the relevant elements without having to interpret these from the resources + pointed to by identifier_parent or walk through eventually deeply nested groups in + individual data instances. + + + + + (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 typically 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 a + region-of-interest connected to individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details. + + + + + Discouraged free-text field to provide further detail. + + + + + + The conventions used when reporting crystal orientations. + We follow the best practices of the Material Science community + that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin. + This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from (improper) Tait-Bryan angles. + + + + + + + + + + + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + Which sign convention is followed when converting orientations + between different parametrizations/representations according + to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. + + + + + + + + + + + + + + + + + + + + + + + + Location of the origin of the processing_reference_frame. + + It is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + + Reference to the specifically named :ref:`NXsample` instance(s) for + which these conventions apply (e.g. /entry1/sample1). + + + + + + + Location of the origin of the sample_reference_frame. + + It is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + The reference frame that is defined by a specific detector. + + + + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). + + + + + + + Location of the origin of the detector_reference_frame. + + If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + + + + + + + + + + + + Details about the control program used for operating the microscope. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A spherical aberration corrector is a typical component in a transmission electron microscope. + Many instruments have only one, in this case the variadic suffix should be dropped. + If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, + corrector_cs2. + + + + Use specifically when there are multiple instances. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Descriptor for the aperture setting 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 users. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Descriptor for the aperture setting 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 users. + + + + + + + + + + + + + + + + + + + + + Operation mode of the detector as displayed by the control software. + + + + + + + + + + + + + + Nominal current of the heater. + + + + + Nominal voltage of the heater. + + + + + + + + + + + + + + + + Documentation for a simulation of electron beam-matter interaction. + + + + The program with which the simulation was performed. + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + Configuration of the simulation + + + + + Results of the simulation + + + + + + + + + + + + + This concept is related to term `Region Of Interest`_ of the EMglossary standard. + + .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml new file mode 100644 index 0000000000..797ffcdb66 --- /dev/null +++ b/applications/nyaml/NXem.yaml @@ -0,0 +1,3529 @@ +category: application +doc: | + Application definition for normalized representation of electron microscopy research. + + This application definition is a comprehensive, general description for the + standardization of data and metadata collected using electron microscopy. + + NXem is designed to be used for documenting experiments or computer simulations in which + controlled electron beams are used to study electron-beam matter interactions, to simulate this, + to explore physical mechanisms and phenomena, or to characterize materials. + + *The NeXus application definition NXem defines a hierarchical data model with ten building blocks:* + + The data model represents a tree of concepts. The tree is constructed from groups of concepts + representing the branches surplus fields and attributes representing leafs. + + *NXem an introduction for typical use cases in material characterization and simulation:* + + Transmission electron microscopy (TEM) and Scanning Transmission Electron Microscopy (STEM) + Scanning Electron Microscopy (SEM) + Scanning Electron Microscopy combined a Focused-Ion Beam (SEM/FIB) + + *A deeper dive into the branches of NXem:* + + NXem is constructed from composing and specializing base classes into the following ten categories: + + - The field ``definition`` specifies that the data schema is NXem. In combination with + administrative metadata such as the ``NeXus_version`` provided by :ref:`NXroot` this + specifies which version of NXem the instance data in a NeXus/HDF5 file are compliant with. + - The fields ``identifier_experiment``, ``experiment_alias``, ``experiment_description`` and + the group ``userID`` provide concepts for storing organizational metadata that + contextualize the work within the research workflow and humans involved in this. + - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. + - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations + that are associated with or notes, i.e. other artifacts that are deemed relevant when reporting about a measurement + or simulation. These groups are useful when NXem is used as a serialization format for technology-partner-agnostic + archival of data and metadata that have been collected during a session with an electron microscope or when a + simulation was performed. + - The group ``sampleID`` provides concepts for storing metadata about the sample that was + characterized or simulated during the session. + - The group ``measurement`` provides concepts that are useful for describing a measurement + during a session with an electron microscope. This includes the chain of events of data and metadata that + were collected during such a session. + - The group``simulation`` provides concepts that are useful for describing a simulation of an + electron beam that interacts with matter. Combined with ``measurement`` this provides a data schema + for defining a digital twin of the microscope and its optical setup. + - The groups ``consistent_rotations``, ``NAMED_reference_frame`` provide concepts for + reporting coordinate systems (frames of reference) and rotation conventions that clarify how data + should be interpreted specifying the rotation of orientable objects in the microscope, its components, + or of crystals and crystal defects in the material analyzed. These metadata support interpretation for + downstream or on-the-fly data analyses which electron microscopes typically nowadays perform + during a session. Examples are the indexing of diffraction patterns, image analysis in general, or + analyses of the chemical composition. + - The group ``roiID`` provides concepts for reporting several domain- and technique-specific + configuration parameter and results of data processing steps that were applied. + - The group ``profiling`` provides concepts for reporting computational details such as + programs and libraries used, for documenting the libraries of virtual environments such as those used + by conda or python virtual environment, including details about the computing hardware used, and + documenting capabilities for performance analyses and benchmarking of the software or its parts. + + *Design choices:* + + Specific details about how an electron microscope was used and eventually its configuration modified differ + between user groups. This holds also true for computer simulations of electron-beam matter interaction. + Different peer groups in different sub-domains in electron microscopy consider different data and metadata + relevant. NXem defines constraints on the existence and cardinality of concepts and its concept branches + but seeks to offer a compromise. The key design pattern followed is that most branches are made optional + or at most recommended but their child concepts conditional required. Thereby, NXem can cover a variety + of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design + is the combination of the optional group ``measurement`` with its required child + ``measurement/instrument``: Users which report simulations are not forced to document the instrument + but users which have characterized a sample are motivated to report about the instrument. They are though not + necessarily required to report all the details of the instruments' components because the design pattern is-used + applied recursively. + + *Inclusive design, one schema for scanning, focused-ion beam, and transmission electron microscopes:* + + Contrary to many other proposals of a data schema for electron microscopy, NXem seeks to highlight the similarity + of the three fundamental types of electron microscopes that are nowadays used most routinely in academia and + industry: An electron microscope is a beamline that provides a controlled beam of electrons combined with eventually + beams of other particles (ions) to investigate electron/ion(-beam) matter interaction. + This design of per-particle-type concept branches is realized in the base classes ``NXebeam_column`` and ``NXibeam_column``. + These provide concepts for reporting the technical components that are typically used for generating a controllable + (and typically scanning) beam of particles such as electrons or ions. + + Focused-ion beam capabilities are modelled by adding an optional group ``measurement/instrument/ibeam_column``. + We foresee that this design is beneficial also in the future when research should be documented where photon-electron + interactions via an electron microscope are combined. The current proposal though does not include such a + ``NXpbeam_column`` base class that could be used for photon-/light-beam, i.e. laser plus optical + beam path descriptions and components. + + We acknowledge that scanning and transmission electron microscopes are different types of instruments that have distinct differences + in the electron-optical setup and the components used. What remains the same from the perspective of an observer who monitors the + experiment inside the electron-matter interaction volume, i.e. in, on, or close to the surface of the specimen is the imaginary split + into an upper and a lower half-space. In the upper half-space a specific but eventually differently shaped electron beam illuminates + the specimen when comparing a scanning with a transmission electron microscope. In the lower half-space the beam or particles exit + the specimen or end up thermalized in thick specimens. + + *NXem distinguishes and stores instance data based on how long they remain unchanged:* + + ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. + The first group is designed for storing metadata about the instrument which do not change over the course of the session. Examples are + the name of the technology partner who built the microscope, the microscope's serial number, or the type of lenses mounted, etc. + The second group is designed for metadata and data that are collected during the microscope session. For these, specializations of + ``NXdata`` specifically ``NXimage`` and ``NXspectrum`` are provided. Each ``measurement/eventID`` event can be time-stamped + individually. Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose + is to store those specific state and settings of the microscope that was present during the collection of the event. + This includes lens settings, apertures used, aberrations, and other components, etc. + By virtue of design this reduces unnecessary repetition of metadata stored in the first group like is often observed + in image-based archival formats like TIFF, PNG, etc. + + *NXem offers domain-specific classes for standardized reporting of method-specific configurations, data processing, and results:* + + These include ``NXem_img`` for generic and specific imaging including diffraction, ``NXem_eds`` for energy-dispersive X-ray spectroscopy, + ``NXem_ebsd`` for electron backscatter diffraction, as well as ``NXem_eels`` for electron energy loss spectroscopy. These branches provide + examples that proof how NeXus can be used for combining session-centric data storage with data processing. These examples are naturally + incomplete but show at different levels of technical depth and breath how standardization can be useful even to report specifically formatted + data representations like multi-dimensional plotting. Thereby, downstream processing using software for data analyses or research data + management can take advantage of a standardized reporting rather than demanding for a zoo of parsers that interconvert + between many representations. + + *NXem within the ecosystem of data schemata for electron microscopy:** + + We support the statement that substantially fewer standardized rather than many ad hoc schemata are required to facilitate the + documentation and exchange of knowledge within electron microscopy. We tailored NXem to serve the materials science and + materials engineering usage of electron microscopy to provide a complementary coverage to what OMERO has established for + the bio- and life science usage of electron microscopy. +type: group +NXem(NXobject): + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] + definition(NX_CHAR): + enumeration: [NXem] + profiling(NXcs_profiling): + exists: optional + doc: | + The configuration of the software that was used to generate this NeXus file. + programID(NXprogram): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + doc: | + A collection of all programs and libraries used to generate this NeXus file. + Ideally, this would enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific set + of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + Instances can also be used to document the modules and libraries that + are offered by the computational environment such as those parsed + from conda or python virtualenv environments. + program(NX_CHAR): + \@version(NX_CHAR): + identifier_experiment(NX_CHAR): + exists: optional + doc: | + A (globally) unique persistent identifier for referring to this experiment. + experiment_alias(NX_CHAR): + exists: optional + doc: | + Alias (short name) which scientists can use to refer to this experiment. + experiment_description(NX_CHAR): + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into the field. + 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 - use this start_time field. + + Often though it is useful to specify a time interval via setting both a start_time + and an end_time because this enables software tools and users to collect a + more detailed bookkeeping of the experiment. + + Users should be aware though that even using only start_time and end_time + may not be sufficient to infer how long the experiment took or for how long + data were acquired. To bookkeep more fine-grained timestamps over the + course of the experiment is possible with start_time and end_time fields + of respective :ref:`NXevent_data_em` instances. + 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. + + See docstring of the start_time field to see how to use the + start_time and end_time together. + citeID(NXcite): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + noteID(NXnote): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doc: | + Collection of serialized resources associated with the experiment. + Examples of such resources are files which are formatted using proprietary + data models of technology partners as those generated by the control software + of the microscope during the instrument session. + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + userID(NXuser): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + doc: | + Information about persons who performed or were involved in the microscope + session or simulation run. + identifierNAME(NX_CHAR): + nameType: partial + exists: recommended + \@type(NX_CHAR): + name(NX_CHAR): + exists: optional + doc: | + Given (first) name and surname. + affiliation(NX_CHAR): + exists: optional + doc: | + Name of the affiliation at the point in time when the experiment was performed. + address(NX_CHAR): + exists: optional + doc: | + Postal address of the affiliation. + email(NX_CHAR): + exists: optional + doc: | + Email address at the point in time when the experiment was performed. + + Writing the most permanently used email is recommended. + telephone_number(NX_CHAR): + exists: optional + doc: | + Telephone number at the point in time when the experiment was performed. + role(NX_CHAR): + exists: optional + doc: | + User role at the point in time when the experiment was performed. + + Examples are technician operating the microscope, student, postdoc, + principle investigator, or guest. + sampleID(NXsample): + exists: ['min', '1', 'max', 'unbounded'] + nameType: partial + doc: + - | + A physical entity which contains material intended to be investigated. + Sample and specimen are treated as de facto synonyms. + Samples can be real or virtual ones as annotated via is_simulation. + - | + The suggested best practice is to call this group sample. In those cases when + multiple samples need to be grouped inside one entry, these SAMPLE groups + should be named using the prefix sample followed an index starting from 1, i.e. + (sample1, sample2). + - | + There are at least two strategies how to store (meta)data when one analyzes multiple + samples - not different ROIs on a single sample though - in one session. + - | + One strategy is to store each sample and its results under an own NXem/ENTRY. + This is one of the most frequent use cases as during most sessions typically only a + single sample is investigated. In this case the name of this group should be sample. + - | + If multiple samples are investigated storing each of them in their own ENTRY group eventually will + demand unnecessary duplication of instrument details. + - | + This can be avoided by using another strategy for storing samples and their results. + Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, + like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., + i.e. instances should use sample as a name prefix. + - | + In this case the collection of events should use identifier_sample to state clearly for which + of the samples loaded the (characterization) event was detected. + - | + xref: + spec: EMglossary + term: Specimen + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 + is_simulation(NX_BOOLEAN): + doc: | + Qualifier whether the sample is a real (in which case is_simulation should be set to false) + or a virtual one (in which case is_simulation should be set to true). + physical_form: + exists: recommended + enumeration: + open_enum: true + items: [bulk, foil, thin_film, powder] + identifier_sample(NX_CHAR): + exists: recommended + doc: | + Ideally, (globally) unique persistent identifier which distinguishes this sample from all others + and especially the predecessor/origin from where that sample was cut off. An example of cutting off + is a steel sheet that is the parent sample from which a small portion was wire-eroded that + represents the sample that was then prepared for characterization with an electron microscope. + + The terms sample and specimen are here considered as exact synonyms. + + This field must not be used for an alias for the sample name. Instead, use name. + + In cases where multiple specimens were loaded into the microscope, the identifier has to resolve + the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single + NXentry should be used for the characterization of a single specimen. + + Details about the specimen preparation should be stored in resources referring to identifier_parent. + \@type(NX_CHAR): + identifier_parent(NX_CHAR): + exists: recommended + doc: | + Identifier of the sample from which the sample was cut off or the string *None*. + I.e. the parent to this sample. + + The purpose of this field is to support functionalities for tracking + sample provenance in a research data management system. + \@type(NX_CHAR): + 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 timestamp when + the measured specimen surface was actively prepared. Ideally, this matches + the last timestamp that is mentioned in the digital resource pointed to by + identifier_parent. + + Knowing when the specimen was exposed to e.g. specific atmosphere is especially + required for material that is sensitive to the environment such as specimens that were + charged with fast diffusing elements or short-lived radioactive tracers. + + Additional time stamps prior to preparation_date are better placed in resources which + describe but do not pollute the description here with prose. Resolving these + connected metadata is considered the responsibility of the research data management + system and not the a NeXus file. + name(NX_CHAR): + exists: recommended + doc: | + Specimen name + atom_types(NX_CHAR): + 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 research data management systems an opportunity + to parse the relevant elements without having to interpret these from the resources + pointed to by identifier_parent or walk through eventually deeply nested groups in + individual data instances. + thickness(NX_NUMBER): + exists: optional + unit: NX_LENGTH + 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 typically 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. + density(NX_NUMBER): + exists: optional + unit: NX_ANY + 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 a + region-of-interest connected to individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details. + description(NX_CHAR): + exists: optional + doc: | + Discouraged free-text field to provide further detail. + consistent_rotations(NXparameters): + exists: recommended + doc: | + The conventions used when reporting crystal orientations. + We follow the best practices of the Material Science community + that are defined in reference ``_. + rotation_handedness(NX_CHAR): + doc: | + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin. + This is in accordance with convention 2 of reference ``_. + + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation according to convention 3 + of reference ``_. + enumeration: [passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of reference ``_. + + The most frequently used convention in Materials Science is zxz, which is based on the work + of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished + from (improper) Tait-Bryan angles. + enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of reference ``_. + enumeration: [rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parametrizations/representations according + to convention 6 of reference ``_. + enumeration: [p_plus_one, p_minus_one] + NAMED_reference_frame(NXcoordinate_system): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + exists: recommended + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + processing_reference_frame(NXcoordinate_system): + exists: recommended + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the processing_reference_frame. + + It is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + sample_reference_frame(NXcoordinate_system): + exists: recommended + depends_on(NX_CHAR): + exists: optional + doc: | + Reference to the specifically named :ref:`NXsample` instance(s) for + which these conventions apply (e.g. /entry1/sample1). + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the sample_reference_frame. + + It is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + detector_reference_frameID(NXcoordinate_system): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + doc: | + The reference frame that is defined by a specific detector. + depends_on(NX_CHAR): + exists: optional + doc: | + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the detector_reference_frame. + + If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: + open_enum: true + items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. + enumeration: + open_enum: true + items: [north, east, south, west, in, out] + measurement(NXem_measurement): + exists: optional + + # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em + instrument(NXinstrument_em): + name(NX_CHAR): + exists: recommended + location(NX_CHAR): + exists: recommended + type(NX_CHAR): + exists: recommended + fabrication(NXfabrication): + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + programID(NXprogram): + exists: recommended + nameType: partial + doc: | + Details about the control program used for operating the microscope. + program(NX_CHAR): + \@version(NX_CHAR): + ebeam_column(NXebeam_column): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + electron_source(NXsource): + exists: recommended + emitter_type(NX_CHAR): + probe(NX_CHAR): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + lensID(NXlens_em): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + apertureID(NXaperture): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + deflectorID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + blankerID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + monochromatorID(NXmonochromator): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + type(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + corrector_csID(NXcorrector_cs): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + doc: | + A spherical aberration corrector is a typical component in a transmission electron microscope. + Many instruments have only one, in this case the variadic suffix should be dropped. + If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, + corrector_cs2. + name(NX_CHAR): + exists: recommended + doc: | + Use specifically when there are multiple instances. + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + corrector_ax(NXcomponent): + exists: ['min', '0', 'max', '1'] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + biprismID(NXcomponent): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + phaseplateID(NXcomponent): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + type(NX_CHAR): + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + beamID(NXbeam): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + scan_controller(NXscanbox_em): + exists: optional + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + ibeam_column(NXibeam_column): + exists: ['min', '0', 'max', '1'] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + ion_source(NXsource): + emitter_type(NX_CHAR): + probe(NXatom): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + lensID(NXlens_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + apertureID(NXaperture): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + deflectorID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + blankerID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + monochromatorID(NXmonochromator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + type(NX_CHAR): + name(NX_CHAR): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + + # device for correcting axial astigmatism of ion beam? + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + beamID(NXbeam): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + scan_controller(NXscanbox_em): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + detectorID(NXdetector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + gas_injector(NXcomponent): + exists: optional + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + stageID(NXmanipulator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + design(NX_CHAR): + exists: recommended + + # add enumeration values from old NXstage_lab + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + nanoprobeID(NXmanipulator): + nameType: partial + exists: optional + fabrication(NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + serial_number(NX_CHAR): + exists: recommended + pumpID(NXpump): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + design(NX_CHAR): + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + eventID(NXevent_data_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + identifier_sample(NX_CHAR): + exists: recommended + + # above field is another example for lacking support to define conditional existence constraints + imageID(NXimage): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + (NXprocess): + exists: recommended + input(NXnote): + exists: recommended + type(NX_CHAR): + file_name(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + context(NX_CHAR): + detector_identifier(NX_CHAR): + image_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + indices_group(NX_INT): + exists: optional + \@long_name(NX_CHAR): + indices_image(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + spectrumID(NXspectrum): + exists: ['min', '0', 'max', 'unbounded'] + nameType: partial + (NXprocess): + exists: recommended + input(NXnote): + exists: recommended + type(NX_CHAR): + file_name(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + context(NX_CHAR): + detector_identifier(NX_CHAR): + spectrum_0d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_0d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + indices_spectrum(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + instrument(NXinstrument_em): + exists: recommended + ebeam_column(NXebeam_column): + operation_mode(NX_CHAR): + exists: recommended + electron_source(NXsource): + exists: optional + voltage(NX_NUMBER): + extraction_voltage(NX_NUMBER): + exists: optional + emission_current(NX_NUMBER): + exists: optional + filament_current(NX_NUMBER): + exists: optional + lensID(NXlens_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + power_setting(NX_CHAR_OR_NUMBER): + apertureID(NXaperture): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + setting(NX_CHAR_OR_NUMBER): + exists: recommended + doc: | + Descriptor for the aperture setting 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 users. + deflectorID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + blankerID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + monochromatorID(NXmonochromator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + applied(NX_BOOLEAN): + dispersion(NX_NUMBER): + exists: recommended + voltage(NX_NUMBER): + exists: recommended + corrector_csID(NXcorrector_cs): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + applied(NX_BOOLEAN): + exists: recommended + tableauID(NXprocess): + nameType: partial + exists: ['min', '1', 'max', 'unbounded'] + + # model(NX_CHAR): + + # ceos + c_1(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_1(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + d_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + r_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_6(NXaberration): + exists: optional + magnitude(NX_NUMBER): + + # nion + c_1_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + + # we could write down how to store the aberrations but we should not force to add aberrations + # basically optional use of NXaberration therein at least some value required + corrector_ax(NXcomponent): + exists: optional + applied(NX_BOOLEAN): + value_x(NX_NUMBER): + value_y(NX_NUMBER): + biprismID(NXcomponent): + nameType: partial + exists: optional + phaseplateID(NXcomponent): + nameType: partial + exists: optional + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + beamID(NXbeam): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + scan_controller(NXscanbox_em): + exists: recommended + scan_schema(NX_CHAR): + dwell_time(NX_NUMBER): + ibeam_column(NXibeam_column): + exists: optional + operation_mode(NX_CHAR): + exists: recommended + ion_source(NXsource): + probe(NXatom): + voltage(NX_NUMBER): + flux(NX_NUMBER): + lensID(NXlens_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + power_setting(NX_CHAR_OR_NUMBER): + apertureID(NXaperture): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + setting(NX_CHAR_OR_NUMBER): + doc: | + Descriptor for the aperture setting 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 users. + deflectorID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + blankerID(NXdeflector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + monochromatorID(NXmonochromator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + applied(NX_BOOLEAN): + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + beamID(NXbeam): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + scan_controller(NXscanbox_em): + exists: recommended + scan_schema(NX_CHAR): + dwell_time(NX_NUMBER): + optics(NXoptical_system_em): + exists: recommended + detectorID(NXdetector): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + operation_mode(NX_CHAR): + doc: | + Operation mode of the detector as displayed by the control software. + stageID(NXmanipulator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + design(NX_CHAR): + exists: recommended + tilt1(NX_NUMBER): + tilt2(NX_NUMBER): + rotation(NX_NUMBER): + position(NX_NUMBER): + sample_heater(NXactuator): + exists: optional + physical_quantity(NX_CHAR): + heater_current(NX_NUMBER): + exists: optional + unit: NX_CURRENT + doc: | + Nominal current of the heater. + heater_voltage(NX_NUMBER): + exists: optional + unit: NX_VOLTAGE + doc: | + Nominal voltage of the heater. + heater_power(NX_NUMBER): + unit: NX_POWER + nanoprobeID(NXmanipulator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + gas_injector(NXcomponent): + exists: optional + pumpID(NXpump): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + sensorID(NXsensor): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + actuatorID(NXactuator): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + simulation(NXem_simulation): + exists: optional + doc: | + Documentation for a simulation of electron beam-matter interaction. + programID(NXprogram): + nameType: partial + exists: recommended + doc: | + The program with which the simulation was performed. + program(NX_CHAR): + \@version(NX_CHAR): + environment(NXcollection): + exists: recommended + doc: | + Programs and libraries representing the computational environment + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program(NX_CHAR): + \@version(NX_CHAR): + config(NXparameters): + exists: optional + doc: | + Configuration of the simulation + results(NXprocess): + exists: optional + doc: | + Results of the simulation + (NXimage): + exists: ['min', '0', 'max', 'unbounded'] + (NXspectrum): + exists: ['min', '0', 'max', 'unbounded'] + interaction_volumeID(NXinteraction_volume_em): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + (NXdata): + exists: recommended + (NXprocess): + exists: recommended + + # relevant research result post-processed for specific community methods + # but normalized in its representation ready to be consumed for + # research data management systems + roiID(NXroi_process): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + doc: | + xref: + spec: EMglossary + term: Region Of Interest + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 + + # as soon as one entry is here constrained further + # an RDM can be sure to find specific pieces of information in a + # specific way but then every user of this application definition + # is required to provide such information in this way! + img(NXem_img): + exists: optional + imageID(NXimage): + nameType: partial + exists: ['min', '1', 'max', 'unbounded'] + imaging_mode(NX_CHAR): + + # (NXmicrostructure): + # exists: optional + ebsd(NXem_ebsd): + exists: optional + gnomonic_reference_frame(NXcoordinate_system): + exists: recommended + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + origin(NX_CHAR): + x(NX_NUMBER): + x_direction(NX_CHAR): + exists: recommended + y(NX_NUMBER): + y_direction(NX_CHAR): + exists: recommended + z(NX_NUMBER): + z_direction(NX_CHAR): + exists: recommended + pattern_center(NXprocess): + exists: recommended + x_boundary_convention(NX_CHAR): + x_normalization_direction(NX_CHAR): + y_boundary_convention(NX_CHAR): + y_normalization_direction(NX_CHAR): + measurement(NXprocess): + exists: optional + depends_on(NX_CHAR): + source(NXnote): + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + simulation(NXprocess): + exists: optional + depends_on(NX_CHAR): + source(NXnote): + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + calibration(NXprocess): + exists: recommended + indexing(NXprocess): + exists: optional + number_of_scan_points(NX_UINT): + indexing_rate(NX_NUMBER): + exists: recommended + source(NXnote): + exists: optional + type(NX_CHAR): + exists: recommended + file_name(NX_CHAR): + checksum(NX_CHAR): + exists: recommended + algorithm(NX_CHAR): + exists: recommended + + # per scan point quantities (identifier_phase, matching_phase, positions, etc.) + # just using the implicit optional, for the database example in NOMAD we do + # not wish to duplicate all payload data + phaseID(NXphase): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + exists: recommended + number_of_scan_points(NX_UINT): + unit_cell(NXunit_cell): + a(NX_NUMBER): + b(NX_NUMBER): + c(NX_NUMBER): + alpha(NX_NUMBER): + beta(NX_NUMBER): + gamma(NX_NUMBER): + space_group(NX_CHAR): + + # foreseen place for phase-specific texture and microstructure representations and statistics + # ipfID(NXmicrostructure_ipf): + # nameType: partial + # exists: ['min', '1', 'max', 'unbounded'] + # color_model(NX_CHAR): + # projection_direction(NX_NUMBER): + # map(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_UINT): + # nameType: partial + # title(NX_CHAR): + # exists: recommended + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # axis_z(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # legend(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_UINT): + # nameType: partial + # title(NX_CHAR): + # exists: recommended + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # \@long_name(NX_CHAR): + # odfID(NXmicrostructure_odf): + # nameType: partial + # exists: optional + # pfID(NXmicrostructure_pf): + # nameType: partial + # exists: optional + # microstructureID(NXmicrostructure): + # nameType: partial + # exists: optional + roi(NXdata): + exists: recommended + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + descriptor(NX_CHAR): + exists: recommended + data(NX_NUMBER): + axis_z(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + eds(NXem_eds): + exists: optional + + # remains to be discussed based on examples + indexing(NXprocess): + summary(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + axis_energy(NX_CHAR): + \@long_name(NX_CHAR): + atom_types(NX_CHAR): + ELEMENT_SPECIFIC_MAP(NXimage): + exists: ['min', '0', 'max', '118'] + iupac_line_candidates(NX_CHAR): + exists: recommended + energy_range(NX_NUMBER): + image_2d(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + intensity(NX_NUMBER): + \@units(NX_CHAR): + exists: recommended + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + \@units(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + \@units(NX_CHAR): + eels(NXem_eels): + exists: optional + + # see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem + # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3c3c9ee91b0f8fdeca130b72ff8c51ce1699a8b63ac5e9416189986c0ff94a50 +# +# +# +# +# +# Application definition for normalized representation of electron microscopy research. +# +# This application definition is a comprehensive, general description for the +# standardization of data and metadata collected using electron microscopy. +# +# NXem is designed to be used for documenting experiments or computer simulations in which +# controlled electron beams are used to study electron-beam matter interactions, to simulate this, +# to explore physical mechanisms and phenomena, or to characterize materials. +# +# *The NeXus application definition NXem defines a hierarchical data model with ten building blocks:* +# +# The data model represents a tree of concepts. The tree is constructed from groups of concepts +# representing the branches surplus fields and attributes representing leafs. +# +# *NXem an introduction for typical use cases in material characterization and simulation:* +# +# Transmission electron microscopy (TEM) and Scanning Transmission Electron Microscopy (STEM) +# Scanning Electron Microscopy (SEM) +# Scanning Electron Microscopy combined a Focused-Ion Beam (SEM/FIB) +# +# *A deeper dive into the branches of NXem:* +# +# NXem is constructed from composing and specializing base classes into the following ten categories: +# +# - The field ``definition`` specifies that the data schema is NXem. In combination with +# administrative metadata such as the ``NeXus_version`` provided by :ref:`NXroot` this +# specifies which version of NXem the instance data in a NeXus/HDF5 file are compliant with. +# - The fields ``identifier_experiment``, ``experiment_alias``, ``experiment_description`` and +# the group ``userID`` provide concepts for storing organizational metadata that +# contextualize the work within the research workflow and humans involved in this. +# - The fields ``start_time``, ``end_time`` provide concepts for framing a temporal context for the research. +# - The groups ``citeID``, ``noteID`` provide concepts for adding contextual details such as citations +# that are associated with or notes, i.e. other artifacts that are deemed relevant when reporting about a measurement +# or simulation. These groups are useful when NXem is used as a serialization format for technology-partner-agnostic +# archival of data and metadata that have been collected during a session with an electron microscope or when a +# simulation was performed. +# - The group ``sampleID`` provides concepts for storing metadata about the sample that was +# characterized or simulated during the session. +# - The group ``measurement`` provides concepts that are useful for describing a measurement +# during a session with an electron microscope. This includes the chain of events of data and metadata that +# were collected during such a session. +# - The group``simulation`` provides concepts that are useful for describing a simulation of an +# electron beam that interacts with matter. Combined with ``measurement`` this provides a data schema +# for defining a digital twin of the microscope and its optical setup. +# - The groups ``consistent_rotations``, ``NAMED_reference_frame`` provide concepts for +# reporting coordinate systems (frames of reference) and rotation conventions that clarify how data +# should be interpreted specifying the rotation of orientable objects in the microscope, its components, +# or of crystals and crystal defects in the material analyzed. These metadata support interpretation for +# downstream or on-the-fly data analyses which electron microscopes typically nowadays perform +# during a session. Examples are the indexing of diffraction patterns, image analysis in general, or +# analyses of the chemical composition. +# - The group ``roiID`` provides concepts for reporting several domain- and technique-specific +# configuration parameter and results of data processing steps that were applied. +# - The group ``profiling`` provides concepts for reporting computational details such as +# programs and libraries used, for documenting the libraries of virtual environments such as those used +# by conda or python virtual environment, including details about the computing hardware used, and +# documenting capabilities for performance analyses and benchmarking of the software or its parts. +# +# *Design choices:* +# +# Specific details about how an electron microscope was used and eventually its configuration modified differ +# between user groups. This holds also true for computer simulations of electron-beam matter interaction. +# Different peer groups in different sub-domains in electron microscopy consider different data and metadata +# relevant. NXem defines constraints on the existence and cardinality of concepts and its concept branches +# but seeks to offer a compromise. The key design pattern followed is that most branches are made optional +# or at most recommended but their child concepts conditional required. Thereby, NXem can cover a variety +# of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design +# is the combination of the optional group ``measurement`` with its required child +# ``measurement/instrument``: Users which report simulations are not forced to document the instrument +# but users which have characterized a sample are motivated to report about the instrument. They are though not +# necessarily required to report all the details of the instruments' components because the design pattern is-used +# applied recursively. +# +# *Inclusive design, one schema for scanning, focused-ion beam, and transmission electron microscopes:* +# +# Contrary to many other proposals of a data schema for electron microscopy, NXem seeks to highlight the similarity +# of the three fundamental types of electron microscopes that are nowadays used most routinely in academia and +# industry: An electron microscope is a beamline that provides a controlled beam of electrons combined with eventually +# beams of other particles (ions) to investigate electron/ion(-beam) matter interaction. +# This design of per-particle-type concept branches is realized in the base classes ``NXebeam_column`` and ``NXibeam_column``. +# These provide concepts for reporting the technical components that are typically used for generating a controllable +# (and typically scanning) beam of particles such as electrons or ions. +# +# Focused-ion beam capabilities are modelled by adding an optional group ``measurement/instrument/ibeam_column``. +# We foresee that this design is beneficial also in the future when research should be documented where photon-electron +# interactions via an electron microscope are combined. The current proposal though does not include such a +# ``NXpbeam_column`` base class that could be used for photon-/light-beam, i.e. laser plus optical +# beam path descriptions and components. +# +# We acknowledge that scanning and transmission electron microscopes are different types of instruments that have distinct differences +# in the electron-optical setup and the components used. What remains the same from the perspective of an observer who monitors the +# experiment inside the electron-matter interaction volume, i.e. in, on, or close to the surface of the specimen is the imaginary split +# into an upper and a lower half-space. In the upper half-space a specific but eventually differently shaped electron beam illuminates +# the specimen when comparing a scanning with a transmission electron microscope. In the lower half-space the beam or particles exit +# the specimen or end up thermalized in thick specimens. +# +# *NXem distinguishes and stores instance data based on how long they remain unchanged:* +# +# ``measurement`` provides two groups ``measurement/instrument`` and ``measurement/eventID``. +# The first group is designed for storing metadata about the instrument which do not change over the course of the session. Examples are +# the name of the technology partner who built the microscope, the microscope's serial number, or the type of lenses mounted, etc. +# The second group is designed for metadata and data that are collected during the microscope session. For these, specializations of +# ``NXdata`` specifically ``NXimage`` and ``NXspectrum`` are provided. Each ``measurement/eventID`` event can be time-stamped +# individually. Each instance of a group ``measurement/eventID`` contains ``measurement/instrument`` whose purpose +# is to store those specific state and settings of the microscope that was present during the collection of the event. +# This includes lens settings, apertures used, aberrations, and other components, etc. +# By virtue of design this reduces unnecessary repetition of metadata stored in the first group like is often observed +# in image-based archival formats like TIFF, PNG, etc. +# +# *NXem offers domain-specific classes for standardized reporting of method-specific configurations, data processing, and results:* +# +# These include ``NXem_img`` for generic and specific imaging including diffraction, ``NXem_eds`` for energy-dispersive X-ray spectroscopy, +# ``NXem_ebsd`` for electron backscatter diffraction, as well as ``NXem_eels`` for electron energy loss spectroscopy. These branches provide +# examples that proof how NeXus can be used for combining session-centric data storage with data processing. These examples are naturally +# incomplete but show at different levels of technical depth and breath how standardization can be useful even to report specifically formatted +# data representations like multi-dimensional plotting. Thereby, downstream processing using software for data analyses or research data +# management can take advantage of a standardized reporting rather than demanding for a zoo of parsers that interconvert +# between many representations. +# +# *NXem within the ecosystem of data schemata for electron microscopy:** +# +# We support the statement that substantially fewer standardized rather than many ad hoc schemata are required to facilitate the +# documentation and exchange of knowledge within electron microscopy. We tailored NXem to serve the materials science and +# materials engineering usage of electron microscopy to provide a complementary coverage to what OMERO has established for +# the bio- and life science usage of electron microscopy. +# +# +# +# +# +# +# +# +# +# The configuration of the software that was used to generate this NeXus file. +# +# +# +# A collection of all programs and libraries used to generate this NeXus file. +# Ideally, this would enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific set +# of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# Instances can also be used to document the modules and libraries that +# are offered by the computational environment such as those parsed +# from conda or python virtualenv environments. +# +# +# +# +# +# +# +# +# A (globally) unique persistent identifier for referring to this experiment. +# +# +# +# +# Alias (short name) which scientists can use to refer to this experiment. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into the 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 - use this start_time field. +# +# Often though it is useful to specify a time interval via setting both a start_time +# and an end_time because this enables software tools and users to collect a +# more detailed bookkeeping of the experiment. +# +# Users should be aware though that even using only start_time and end_time +# may not be sufficient to infer how long the experiment took or for how long +# data were acquired. To bookkeep more fine-grained timestamps over the +# course of the experiment is possible with start_time and end_time fields +# of respective :ref:`NXevent_data_em` instances. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included when +# the microscope session ended. +# +# See docstring of the start_time field to see how to use the +# start_time and end_time together. +# +# +# +# +# +# Collection of serialized resources associated with the experiment. +# Examples of such resources are files which are formatted using proprietary +# data models of technology partners as those generated by the control software +# of the microscope during the instrument session. +# +# +# +# +# +# +# +# +# Information about persons who performed or were involved in the microscope +# session or simulation run. +# +# +# +# +# +# +# Given (first) name and surname. +# +# +# +# +# Name of the affiliation at the point in time when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address at the point in time when the experiment was performed. +# +# Writing the most permanently used email is recommended. +# +# +# +# +# Telephone number at the point in time when the experiment was performed. +# +# +# +# +# User role at the point in time when the experiment was performed. +# +# Examples are technician operating the microscope, student, postdoc, +# principle investigator, or guest. +# +# +# +# +# +# A physical entity which contains material intended to be investigated. +# Sample and specimen are treated as de facto synonyms. +# Samples can be real or virtual ones as annotated via is_simulation. +# +# The suggested best practice is to call this group sample. In those cases when +# multiple samples need to be grouped inside one entry, these SAMPLE groups +# should be named using the prefix sample followed an index starting from 1, i.e. +# (sample1, sample2). +# +# There are at least two strategies how to store (meta)data when one analyzes multiple +# samples - not different ROIs on a single sample though - in one session. +# +# One strategy is to store each sample and its results under an own NXem/ENTRY. +# This is one of the most frequent use cases as during most sessions typically only a +# single sample is investigated. In this case the name of this group should be sample. +# +# If multiple samples are investigated storing each of them in their own ENTRY group eventually will +# demand unnecessary duplication of instrument details. +# +# This can be avoided by using another strategy for storing samples and their results. +# Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, +# like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., +# i.e. instances should use sample as a name prefix. +# +# In this case the collection of events should use identifier_sample to state clearly for which +# of the samples loaded the (characterization) event was detected. +# +# This concept is related to term `Specimen`_ of the EMglossary standard. +# +# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 +# +# +# +# Qualifier whether the sample is a real (in which case is_simulation should be set to false) +# or a virtual one (in which case is_simulation should be set to true). +# +# +# +# +# +# +# +# +# +# +# +# +# Ideally, (globally) unique persistent identifier which distinguishes this sample from all others +# and especially the predecessor/origin from where that sample was cut off. An example of cutting off +# is a steel sheet that is the parent sample from which a small portion was wire-eroded that +# represents the sample that was then prepared for characterization with an electron microscope. +# +# The terms sample and specimen are here considered as exact synonyms. +# +# This field must not be used for an alias for the sample name. Instead, use name. +# +# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve +# the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single +# NXentry should be used for the characterization of a single specimen. +# +# Details about the specimen preparation should be stored in resources referring to identifier_parent. +# +# +# +# +# +# Identifier of the sample from which the sample was cut off or the string *None*. +# I.e. the parent to this sample. +# +# The purpose of this field is to support functionalities for tracking +# sample provenance in a research data management system. +# +# +# +# +# +# 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 timestamp when +# the measured specimen surface was actively prepared. Ideally, this matches +# the last timestamp that is mentioned in the digital resource pointed to by +# identifier_parent. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is especially +# required for material that is sensitive to the environment such as specimens that were +# charged with fast diffusing elements or short-lived radioactive tracers. +# +# Additional time stamps prior to preparation_date are better placed in resources which +# describe but do not pollute the description here with prose. Resolving these +# connected metadata is considered the responsibility of the research data management +# system and not the a NeXus file. +# +# +# +# +# Specimen name +# +# +# +# +# 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 research data management systems an opportunity +# to parse the relevant elements without having to interpret these from the resources +# pointed to by identifier_parent or walk through eventually deeply nested groups in +# individual data instances. +# +# +# +# +# (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 typically 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 a +# region-of-interest connected to individual :ref:`NXevent_data_em` +# instances can provide a cleaner description of the relevant details. +# +# +# +# +# Discouraged free-text field to provide further detail. +# +# +# +# +# +# The conventions used when reporting crystal orientations. +# We follow the best practices of the Material Science community +# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin. +# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) +# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# The most frequently used convention in Materials Science is zxz, which is based on the work +# of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished +# from (improper) Tait-Bryan angles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parametrizations/representations according +# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Location of the origin of the processing_reference_frame. +# +# It is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the specifically named :ref:`NXsample` instance(s) for +# which these conventions apply (e.g. /entry1/sample1). +# +# +# +# +# +# +# Location of the origin of the sample_reference_frame. +# +# It is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The reference frame that is defined by a specific detector. +# +# +# +# Reference to the specifically named :ref:`NXdetector` instance for +# which these conventions apply (e.g. /entry1/instrument/detector1). +# +# +# +# +# +# +# Location of the origin of the detector_reference_frame. +# +# If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the control program used for operating the microscope. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A spherical aberration corrector is a typical component in a transmission electron microscope. +# Many instruments have only one, in this case the variadic suffix should be dropped. +# If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, +# corrector_cs2. +# +# +# +# Use specifically when there are multiple instances. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptor for the aperture setting 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 users. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptor for the aperture setting 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 users. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Operation mode of the detector as displayed by the control software. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Nominal current of the heater. +# +# +# +# +# Nominal voltage of the heater. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Documentation for a simulation of electron beam-matter interaction. +# +# +# +# The program with which the simulation was performed. +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# Configuration of the simulation +# +# +# +# +# Results of the simulation +# +# +# +# +# +# +# +# +# +# +# +# +# This concept is related to term `Region Of Interest`_ of the EMglossary standard. +# +# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml new file mode 100644 index 0000000000..faca9e7310 --- /dev/null +++ b/base_classes/NXaberration.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + For an introduction in the aberrations in electron microscopy + see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and + `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. + Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. + + + + Magnitude of the aberration + + + + + Uncertainty of the magnitude of the aberration + + + + + Free-text description how magnitude_errors was quantified + e.g. via the 95% confidence interval, variance, standard deviation, + using which algorithm or statistical model. + + + + + Time elapsed since the last measurement. + + + + + 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. + + + + + Given name to this aberration. + + + + + Alias to name or refer to this specific type of aberration. + + + diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..2ad203b8fc --- /dev/null +++ b/base_classes/NXcorrector_cs.nxdl.xml @@ -0,0 +1,169 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of images taken, at least one. + + + + + Base class for a corrector reducing (spherical) aberrations in electron microscopy. + + Different technology partners use different conventions and + models for quantifying the aberration coefficients. + + Correctors in an electron microscope are composed of multiple lenses + and multipole stigmators. Their technical details are specific for the + technology partner as well as microscope. Most technical details are + proprietary knowledge. + + If one component corrects for multiple types of aberrations (like it is the case + reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this + design when using corrector and monochromator in an application definition: + + * Use :ref:`NXcorrector_cs` for spherical aberration + * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration + * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration + + + + + Was the corrector used? + + + + + Specific information about the alignment procedure. This is a process during which + the corrector is configured to enable calibrated usage of the instrument. + + This :ref:`NXprocess` group should also be used when one describes in a computer + simulation the specific details about the modelled or assumed aberrations. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau acquisition. + + TODO: The relevant axes which span the tilt_angle need a + cleaner description. Suggestions from the community are + welcome here for guiding an improvement of this base class. + + + + + + + + The exposure time of single tilt images. + + + + + + + + The factor of enlargement of the apparent size, + not the physical size, of an object. + + + + + + + + Image(s) taken during the alignment procedure + + + + + Convention used for storing measured or estimated aberrations (for each or the final image) + via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. + + 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. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml index 7905c13e92..7c67e0c67b 100644 --- a/base_classes/NXcs_profiling.nxdl.xml +++ b/base_classes/NXcs_profiling.nxdl.xml @@ -41,7 +41,7 @@ information across a network and these are used usually by multiple users. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software i.e. an app took. + analysis with a scientific software, i.e. an app took. A frequent idea is here to answer practical questions like how critical is the effect on the workflow of the scientists, i.e. is the analysis possible in a few seconds or would it take days if I were to run this analysis on a diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml new file mode 100644 index 0000000000..2901558992 --- /dev/null +++ b/base_classes/NXebeam_column.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + Base class for a set of components providing a controllable electron beam. + + The idea behind defining NXebeam_column as an own base class vs. adding these + concepts in NXinstrument_em is that the electron beam generating component + might be worthwhile to use also in other types of experiments. + + + + Tech-partner, microscope-, and control-software-specific name of the + specific operation mode how the ebeam_column and its components are + controlled to achieve specific illumination conditions. + + In many cases the users of an instrument do not or can not be expected to know + all intricate spatiotemporal dynamics of their hardware. Instead, they rely on + assumptions that the instrument, its control software, and components work as + expected to focus on their research questions. + + For these cases, having a place for documenting the operation_mode is useful + in as much as at least some constraints on how the illumination conditions were + is documented. + + + + + A physical part of an electron or ion microscope from which + the particles that form the beam are emitted. + + The hardware for an electron source in an electron microscope + may contain several components which affect the beam path. + + This concept is related to term `Source`_ of the EMglossary standard. + + .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 + + + + The potential difference between anode and cathode. + + This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. + + .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 + + + + + Voltage which is used to create an electric field that draws particles from + the source. + + This concept is related to term `Extraction Voltage`_ of the EMglossary standard. + + .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + + + + + Electrical current which is released from the source. + + This concept is related to term `Emission Current`_ of the EMglossary standard. + + .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + + + + + Electrical current which flows through the source. + + This concept is related to term `Filament Current`_ of the EMglossary standard. + + .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 + + + + + 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. + + + + + + How long has the source been in operation. + + + + + + + + + A component for blanking the beam or generating pulsed electron beams. + See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ + or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. + + + + + Device to improve energy resolution or chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + + + + + Qualitative type of the component. + + + + + + + + + + + + + + Was the corrector used? + + + + + + Energy dispersion in e.g. µm/eV. + + + + + Corresponding voltage for that energy dispersion. + + + + + + + Component that reshapes an ellipse-shaped electron beam into a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. + + + + 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 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 users. + + + + + + Electron biprism as it is used e.g. for electron holography. + + + + + Device that causes a change in the phase of an electron wave. + + * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ + * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ + + + + Qualitative type + + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the electron beam at a given location. + + :ref:`NXtransformations` should be used to specify the location + or the position at which details about the beam were probed. + + This concept is related to term `Electron Beam`_ of the EMglossary standard. + + .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 + + + + + diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml new file mode 100644 index 0000000000..c8959b455d --- /dev/null +++ b/base_classes/NXem_ebsd.nxdl.xml @@ -0,0 +1,678 @@ + + + + + + + + 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 plot orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. + + + + + Number of phase solutions + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Base class method-specific for Electron Backscatter Diffraction (EBSD). + + The general procedure of an EBSD experiment is as follows: + Users load the specimen, collect first a coarse image of the surface. + Next, they set an approximate value for the calibrated working distance + and tilt the stage into diffraction conditions. + + Users then typically configure the microscope for collecting quality data. + The EBSD detector is pushed in (if retractable). Subsequently, they fine tune + the illumination and aberration corrector settings and select one or multiple ROIs + for the microscope to machine off automatically. They configure on-the-fly + indexing parameter and then typically start the measurement queue. + From this point onwards typically the microscope runs automatically. + + Diffraction pattern get collected until the queue finishes or gets interrupted by + either errors or arrival at the end of the users' allocated timeslot at the instrument. + + Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. + Once indexed, these patterns are often not stored. + + Results are stored in files, which afterwards are typically copied + automatically or manually for archival purposes to certain storage + locations for further consumption. The result of such an EBSD + measurement/experiment is a set of usually proprietary or open files + from technology partners. + + This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific + data, metadata, and connections between these for the research field of + electron microscopy exemplified here for electron backscatter diffraction (EBSD). + The base class solves two key documentation issues within the EBSD community: + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted + according to NXem_ebsd) stores the connection between the microscope session and + the key datasets which are considered typically results of the afore-mentioned + steps involved in an EBSD experiment. + + Different groups in NXem_ebsd make connections to data artifacts which were collected + when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, + associated overview images, like secondary electron or backscattered electron + images of the region-of-interest probed, and many more (meta)data. + + Secondly, NXem_ebsd connects and stores the conventions and reference frames + which were used and which are the key to a correct mathematical interpretation + of every experiment or simulation using EBSD. + + Otherwise, results would be ripped out of their context like it is the current situation + with many traditional studies where EBSD data were indexed on-the-fly and shared + with the community only via sharing the strongly processed files with results in some + formatting but without communicating all conventions used or just relying on the assumptions + that colleagues likely know these conventions even though + multiple definitions are possible. + + NXem_ebsd 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) experiments + where a combination of repetitive removal of material from the surface layer to measure + otherwise the same region-of-interest at different depth increments. Material removal + can be achieved with mechanical, electron, or ion polishing, using manual steps or + automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By virtue of design, these methods are destructive + either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these images are indexed to process + a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint + also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. + + This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. + + .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 + + + + Details about the gnomonic (projection) reference frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions are not met, the user is required to explicitly state this. + + Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the + base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. + + + + Origin of the gnomonic_reference_frame. + + Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to + assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. + + + + + + + + Direction of the positively pointing x-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + + Details about the definition of the pattern center as a special point in the + gnomonic_reference_frame. + + Typically the gnomonic space is embedded in the detector space. + Specifically, the XgYg plane is defined such that it is 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 + one effectively normalizes in fractions of the width of the detector. + + The issue with terms like width and height, though, is that these become degenerated + if the detector region-of-interest is square-shaped. This is why instead of referring to + width and height it is better to state explicitly which direction is considered positive + when measuring distances. + + For the concepts used to specify the boundary_convention it is assumed that the + region-of-interest is defined by a rectangle, referring to the direction of outer-unit + normals to the respective edges of this rectangle. + + + + From which border of the EBSP (in the detector reference frame) is the pattern + center's x-position (PCx) measured. + + + + + + + + + + + In which direction are positive values for the x-axis coordinate value measured + from the specified boundary. + + + + + + + + + + + From which border of the EBSP (in the detector reference frame) is the pattern + center's y-position (PCy) measured. + + + + + + + + + + + In which direction are positive values for the y-axis coordinate value measured + from the specified boundary. + + + + + + + + + + + + This group documents relevant details about the conditions and the + tools for measuring diffraction patterns with an electron microscope. + + The most frequently collected EBSD data are captured for rectangular + regions-of-interest using a discretization into square or hexagon tiles. + + + + Physical time since the beginning of a timestamp that is required to be + the same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set need 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, + 30 minutes, 6 hours, or 24 hours of annealing. + + + + Timestamp relative to which time was counted to aid + converting between time and timestamp. + + + + + + Path to an instance of :ref:`NXdata` where the measured patterns are stored. + + + + + Reference (e.g. path and filename) to an existent data artifact which + stores either the measured patterns or input (already processed EBSD data). + + + + + + This group documents relevant details about the conditions and the tools + used for simulating diffraction patterns with some physical model. + + This group should be used if (e.g. instead of a measurement) the patterns + were simulated (possibly awaiting indexing). + + In many practical cases where patterns are analyzed on-the-fly and dictionary + indexing strategies used, so-called master pattern(s) are used to compare + measured or simulated patterns with the master patterns. + + + + Path to an instance of :ref:`NXimage` where the simulated patterns are stored. + + + + + Reference (e.g. path and filename) to an existent digital resource which + stores either the patterns or input (already processed EBSD data) that are + about to become processed further as described by this NXem_ebsd instance. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilt, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable, precise, and accurate scientific results. + + Specifically, the gnomonic projection has to be calibrated. + Typically, standard specimens made from silicon or quartz crystals + in specific orientations are used for this purpose. + + Considering that a system used is already calibrated well-enough is much + more frequently the case in practice than that users perform the calibration + themselves (with above-mentioned standard specimens). + + 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 has been calibrated already. Consequently, users pick from + an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. + Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). + + In the second case, users calibrate the system during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how the + reference frames are configured and how this setup in the GUI. + + 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' obligation to remember these + settings or write these down in a lab notebook. Otherwise, these metadata + get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` + solves in that all conventions can be specified explicitly. + + + + Path to an instance of :ref:`NXem` where calibration data are stored. + + + + + Reference to a digital resource where the calibration is stored. + + + + + + Indexing is a data processing step performed either after or while (aka on-the-fly) + the beam scans the specimen. The resulting method is also + known as orientation imaging microscopy (OIM). + + Different algorithms can be used to index EBSP. Common to them is the + computational step where simulated or theoretically assumed patterns + are compared with the measured ones. These latter patterns are referred + to via the measurement or simulation groups of this base class respectively. + + Quality descriptors are defined based on which an indexing algorithm + yields a quantitative measure of how similar measured and reference + patterns are, and thus if no, one, or multiple so-called solutions were found. + + Assumed or simulated patterns are simulated using kinematical or dynamical + theory of electron diffraction delivering master patterns. + + The Hough transform, one of the most frequently used traditional method for indexing + EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods + find more widespread usage for indexing. + + + + This group enables to establish a logical connection between previous + processing steps or on-the-fly-performed indexing of the EBSD map. + Typically these processing steps are performed with commercial software. + Therefore, in many cases a results file from this indexing is often + all that is communicated and saved. These are typically files in a format + specific to the instrument and its configuration. + + Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. + + + + + Principal algorithm used for indexing. + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + Binning i.e. downsampling to each pattern. + + + + + Specific parameter relevant only for certain algorithms used. + + + + + Details for each phase used as a model with which the patterns were + indexed. Instances of :ref:`NXunit_cell` in this group must + have the group name prefixed with phase. The identifier in the name is an + integer. Start counting from 1 because the value 0 is reserved for + the special phase that is the null-model, the null phase also known + as notIndexed. + + + + Spacing between the crystallographic planes that are defined via ``miller``. + + + + + + + + Relative intensity for the computed diffraction intensity (signal) for the + plane. + + + + + + + + In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps + this field stores how many scan points of the map were identified as matching best + with this phase. + + + + + How many reflectors for crystallographic planes are distinguished. + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + + * 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 :ref:`NXunit_cell`. + + In another example users may have skipped some scan points (not indexed + them at all) or used differing numbers of phases for indexing different scan points. + + The cumulated of this array decodes how identifier_phase and matching_phase + 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), + identifier_phase has as many entries as scan points + and matching_phase has also as many entries as scan points. + + + + + + + + The array phases_per_scan_point details how the identifier_phase + and the matching_phase arrays have to be interpreted. + + For the example with a single phase identifier_phase 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 + required) that a pattern matches eventually (not equally well) sufficiently + significant with multiple patterns. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models. Having such field is especially relevant + for recent dictionary- or artificial intelligence-based indexing methods to communicate + the results in a model-agnostic way in combination with matching_phase. + + Depending on the phases_per_scan_point value, identifier_phase and + matching_phase arrays represent a collection of concatenated tuples. + These 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 phases_per_scan_point. + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array phases_per_scan_point has to be specified because it details + how the identifier_phase and the matching_phase arrays are interpreted. + See documentation of identifier_phase for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence_index, mean_angular_deviation, or other. + + + + + + + + + + + Calibrated center positions of each scan point + in the sample surface reference system. + + + + + + + + + Fraction of successfully indexed patterns with a phase + not the null-phase vs the number_of_scan_points. + + + + + Number of scan points in the original mapping. + + + + + + An overview of the entire ROI. + + + + Descriptor representing the image contrast. + + + + + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + Descriptor values + + + + + + Calibrated coordinate along the y-axis. + + + + + + + Label for the y axis + + + + + + Calibrated coordinate along the x-axis. + + + + + + + Label for the x axis + + + + + + diff --git a/base_classes/NXem_eds.nxdl.xml b/base_classes/NXem_eds.nxdl.xml new file mode 100644 index 0000000000..31d4beb20c --- /dev/null +++ b/base_classes/NXem_eds.nxdl.xml @@ -0,0 +1,200 @@ + + + + + + + + Number of X-ray photon energy (bins) + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Number of IUPAC line names + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental + characterization requires typically a sequence of characterization and preparation of the + surface to expose new surface layer that can be characterized in the next acquisition. + In effect, the resulting three-dimensional elemental information mappings are truly the + result of a correlation and post-processing of several measurements which is the field + of correlative tomographic usage of electron microscopy. + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Accumulated intensity over all pixels of the region-of-interest. + + + + Accumulated counts + + + + + + + Counts + + + + + + Energy axis + + + + + + + Energy + + + + + + + Comma-separated list of symbols for elements from the periodic table that have + been confirmed present by the here reported EDS analysis. + + This field can be used when creating instances of :ref:`NXpeak` is not desired. + However, a collection of instances of NXpeak with individual NXatom + can be used to add isotopic information and other relevant context. + + + + + Details about individual indexed peaks. + + + + + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + + + + + + + + Theoretical energy of the line according to IUPAC. + + + + + 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 grouped with the same peak. + + + + + + + + + + Individual element-specific EDS/EDX/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. + + These element-specific EDS maps are instances of :ref:`NXimage` + that should be named by the element from the atom_types field. + + When signal contributions from several peaks were decomposed + users should ideally use a respective number of NXpeak instances + to give further context about the individual signal contributions + are summarized and shown together, e.g. the combined signal + under the curve of carbon and oxygen. + + In this case specify the processing details use peak and weight. + + + + Discouraged free-text field to add additional information. + + + + + Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that + documents which elements and their specific lines are theoretically located within + the energy_range of the spectrum from which the EDS (element) map was computed. + + + + + Associated :math:`[e_{min}, e_{max}]` bounds of the energy + range for which spectrum counts were accumulated. + + + + + + + + + A list of :ref:`NXpeak` instance names whose X-ray quanta were + accumulated for each pixel to obtain an element-specific + EDS map. + + + + + + + + A list of weights by how much the intensity of each peak + contributes to the intensity of the EDS map. + + + + + + diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml new file mode 100644 index 0000000000..f76b090dea --- /dev/null +++ b/base_classes/NXem_eels.nxdl.xml @@ -0,0 +1,58 @@ + + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + Details about computational steps how the zero-loss peak was threaded. + + + + The program with which the zero-loss peak correction was performed. + + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each peak in the spectrum considered to be of relevance. + + + + + NXspectrum specialized for EELS. + + + + diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml new file mode 100644 index 0000000000..10c580be31 --- /dev/null +++ b/base_classes/NXem_img.nxdl.xml @@ -0,0 +1,62 @@ + + + + + + Base class for method-specific generic imaging with electron microscopes. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe regions-of-interest (ROIs). Examples can be single point aka spot + measurements, 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. + + + + + Which imaging mode was used? + + + + + + + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/base_classes/NXem_measurement.nxdl.xml b/base_classes/NXem_measurement.nxdl.xml new file mode 100644 index 0000000000..4648fe57ac --- /dev/null +++ b/base_classes/NXem_measurement.nxdl.xml @@ -0,0 +1,30 @@ + + + + + + Base class for documenting a measurement with an electron microscope. + + + + diff --git a/base_classes/NXem_simulation.nxdl.xml b/base_classes/NXem_simulation.nxdl.xml new file mode 100644 index 0000000000..6ec01a7965 --- /dev/null +++ b/base_classes/NXem_simulation.nxdl.xml @@ -0,0 +1,32 @@ + + + + + + Base class for documenting a simulation of electron beam-matter interaction. + + + + + + diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml new file mode 100644 index 0000000000..c26a78a7e6 --- /dev/null +++ b/base_classes/NXevent_data_em.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + Base class to store state and (meta)data of events for electron microscopy. + + Event-related (meta)data, typically measured datasets like images and spectra. + To avoid repetitively storing static instrument-related metadata, + the dynamic (meta)data that typically changes for each image and spectrum + is split from the static (meta)data. + + Which temporal granularity is adequate to log events depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + + Electron microscopes are dynamic. Scientists often report that microscopes + *perform differently* across sessions. That *they* perform differently from + one day or another. In some cases, root causes for performance differences + are unclear. Users of the instrument may consider such conditions impractical, + or *too poor*, and thus abort their session. Alternatively, users may try to + bring the microscope into a state where conditions are considered better + or of whatever high enough quality for starting or continuing the measurement. + + In all these use cases it is useful to have a mechanism whereby time-dependent + data of the instrument state can be stored and documented in an representation + that facilitates interoperability. This is the idea behind this base class. + + :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly + whatever is considered a time interval during which the instrument is + considered stable enough for allowing any working on tasks with it. + Examples of such tasks are the collecting of data (images and spectra) or + the calibrating the instrument or individual of its components. Users may wish to take + only a single scan or image and complete their session thereafter. + Alternatively, users are working for much longer time at the instrument, + perform recalibrations in between and take several scans (of different + ROIs on the specimen), or they explore the state of the microscope for + service or maintenance tasks. + + :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: + + * Firstly, via a header section whose purpose is to contextualize + and identify the event instance in time. + * Secondly, via a data and metadata section where individual data + collections can be stored in a standardized representation. + + We are aware of the fact that given the variety how an electron microscope + is used, there is a need for a flexible and adaptive documentation system. + At the same time we are also convinced though that just because one has + different requirements for some specific aspect under the umbrella of settings + to an electron microscope, this does not necessarily warrant that one has to + cook up an own data schema. + + Instead, the electron microscopy community should work towards reusing schema + components as frequently as possible. This will enable that there is at all + not only a value of harmonizing electron microscopy research content but also + there is a technical possibility to build services around such harmonized data. + + 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 a stack of spectra. Having to deal with instabilities is a common theme in + electron microscopy practice. Numerical protocols can be used during data + post-processing to correct for some of the instabilities. + A few exemplar references provide an overview on the subject: + + * `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 (digital twin), 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 and ions, or detector noise models. + This also warrants to document the time-dependent details of individual components + of the microscope via the here implemented class :ref:`NXevent_data_em`. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. + + If users wish 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. + + + + + Identifier of a specific state and setting of the microscope. + + + + + The name of the sample to resolve ambiguities. + + + + + 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 for which there is at the moment no other place. + + In the long run such free-text field description should be avoided as + it is difficult to machine-interpret. Instead, an enumeration should + be used. + + + + + + + diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml new file mode 100644 index 0000000000..9d5576e3f1 --- /dev/null +++ b/base_classes/NXibeam_column.nxdl.xml @@ -0,0 +1,155 @@ + + + + + + Base class for a set of components equipping an instrument with FIB capabilities. + + Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped + with sufficient ion having sufficient momentum to remove material in a controlled + manner. + + The fact that an electron microscope with FIB capabilities achieves these functionalities + via a second component (aka the ion gun) that has its own relevant control circuits, + focusing lenses, and other components, warrants the definition of 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>`_ + * `N. Yao <https://doi.org/10.1017/CBO9780511600302>`_ + + + + Tech-partner, microscope-, and control-software-specific name of the + specific operation mode how the ibeam_column and its components are + controlled to achieve specific illumination conditions. + + In many cases the users of an instrument do not or can not be expected to know + all intricate spatiotemporal dynamics of their hardware. Instead, they rely on + assumptions that the instrument, its control software, and components work as + expected to focus on their research questions. + + For these cases, having a place for documenting the operation_mode is useful + in as much as at least some constraints on how the illumination conditions were + is documented. + + + + + 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 elements, ions, or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + Average/nominal flux + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and + entering the vacuum flight path. + + + + + To be defined more specifically. Community suggestions are welcome. + + + + + + + + + A component for blanking the ion beam or generating pulsed ion beams. + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + :ref:`NXtransformations` should be used to specify the location or position + at which details about the ion beam are probed. + + + + + + diff --git a/base_classes/NXimage.nxdl.xml b/base_classes/NXimage.nxdl.xml index 8859586bc5..d425fd0019 100644 --- a/base_classes/NXimage.nxdl.xml +++ b/base_classes/NXimage.nxdl.xml @@ -29,9 +29,14 @@ Number of images in the stack, for stacks the slowest dimension. + + + Number of image points along the slowest dimension. + + - Number of image points along the slow dimension (k equivalent to z). + Number of image points along the slow dimension. @@ -56,10 +61,9 @@ pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - image point is eventually more appropriate when working with such tilings. + (image) point is eventually more appropriate when working with such tilings. - Therefore, all docstrings in this base class refer to points. Points are considered - exact synonyms for pixel and voxel, which are terms used for regular tilings. + Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). Point coordinates identify the location of the barycenter. @@ -85,6 +89,17 @@ That is indices_image are always counting from offset in increments of one as each image is its own entity. By contrast, a group may contain no, or several images. Consequently, indices_group are not required to be contiguous. + + Classically, images depict objects in real space. Such usage of NXimage essentially is equivalent to + storing pictures. For this purpose the image_1d, image_2d, or image_3d NXdata instances respectively + should be used with all their axes axis_i, axis_j, axis_k constrained to NeXus Unit Category NX_LENGTH. + + Imaging modes in electron microscopy are typically more versatile, specifically for use cases + in scanning transmission electron microscopy, so-called 4DSTEM. In this case, one two-dimensional + diffraction image is taken for each point that gets scanned in real space. Consequently, + image_3d and image_4d NXdata instances should be used for these cases with axis_k and axis_m + respectively of NeXus Unit Category NX_LENGTH and axis_i and axis_j respectively of + NeXus Unit Category NX_WAVENUMBER. @@ -159,9 +174,14 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -215,9 +235,14 @@ - + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -228,9 +253,14 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -288,9 +318,14 @@ - + Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -301,9 +336,14 @@ - + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -314,9 +354,137 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Four-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + + + + + + + + + + + Point coordinate along the slowest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + + + + + + + Point coordinate along the slowest dimension. + + + + + + Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -396,9 +564,14 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -482,9 +655,14 @@ - + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -495,9 +673,14 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -585,9 +768,14 @@ - + Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -598,9 +786,14 @@ - + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. @@ -611,9 +804,14 @@ - + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. diff --git a/base_classes/NXinstrument_em.nxdl.xml b/base_classes/NXinstrument_em.nxdl.xml new file mode 100644 index 0000000000..a46b7ecdb1 --- /dev/null +++ b/base_classes/NXinstrument_em.nxdl.xml @@ -0,0 +1,232 @@ + + + + + + Base class for instrument-related details of a real or simulated electron microscope. + + For collecting data and experiments which are simulations of an electron + microscope (or such session) use the :ref:`NXem` application definition and + the :ref:`NXevent_data_em` groups it provides. + + This base class implements the concept of :ref:`NXem` whereby (meta)data are distinguished + whether these typically change during a session (dynamic) or not (static metadata). + This design allows to store e.g. hardware related concepts only once instead of demanding + that each image or spectrum from the session needs to be stored also with the static metadata. + + + + 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. + + + + + Different types of electron microscopes exist: + + * sem, a scanning electron microscope without focused-ion beam capabilities + * fib, a scanning electron microscope with focused-ion beam capabilities + irrespective whether these were used or not + * tem, a transmission electron microscope + + NXem is one joint data model that can be used to document research that is performed + with several of these types of microscopes (SEM, TEM, or FIB). The NXem data model + stresses that these types of instruments despite having several differences are still all + electron beamlines with which to probe electron and/or ion matter interaction and in fact + in practice have many similarities in how they are used, the components, they contain, etc. + + This field can be used in research data management systems for enabling a categorization + or tagging of experiments without having to analyze if groups like NXibeam_column are present + (which would indicate type is fib) or if certain lens configurations or instrument models are used + which suggests the microscope is a scanning (sem) or transmission electron microscope (tem): + + + + + + + + + + + + + + + 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. + + + + + Stages in an electron microscope are multi-functional devices. + + Stages enable experimentalists the application of controlled external stimuli + on the specimen. Modern stages realize a hierarchy of components. + A multi-axial tilt rotation holder is a good example where the control of + each degree of freedom is technically implemented via providing instances + of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating + and positioning of the specimen. + + The physical process of mounting a specimen on a stage in practice often + comes with an own hierarchy of fixtures to bridge e.g. length scales technically. + An example from atom probe microscopy is that researchers may work + with wire samples which are clipped into a larger fixing unit to enable + careful specimen handling. Alternatively, a microtip is a silicon post + upon which e.g. an atom probe specimen is mounted. Multiple of such microtips + are then grouped into a microtip array to conveniently enable loading of multiple + specimens into the instrument with fewer operations. There are further scenarios + typically encountered related to mounting and locating specimens inside an + electron microscope, a few examples follow: + + * A nanoparticle on a copper grid. The copper grid is the holder. + This grid itself is fixed to a stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. A typical + example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Free-text field to give a term how that a stage_lab at this level of the + stage_lab hierarchy is commonly referred to. Examples could be stub, + puck, carousel, microtip, clip, holder, etc. + + + + + + The interpretation of this tilt1 value can be contextualized via the comment + attribute. However, it is better to describe the reference frame in which the + tilt is defined explicitly using instances of :ref:`NXtransformations` and + respective instances of :ref:`NXcoordinate_system`. Especially when this + NXinstrument_em base class is used in an application definition like NXem. + + + + Discouraged free-text field to provide details about how to interpret tilt1. + + + + + + The interpretation of this tilt2 value can be contextualized via the comment + attribute. However, it is better to describe the reference frame in which the + tilt is defined explicitly using instances of :ref:`NXtransformations` and + respective instances of :ref:`NXcoordinate_system`. Especially when this + NXinstrument_em base class is used in an application definition like NXem. + + + + Discouraged free-text field to provide details about how to interpret tilt2. + + + + + + The interpretation of this rotation value can be contextualized via the comment + attribute. However, it is better to describe the reference frame in which the + rotation is defined explicitly using instances of :ref:`NXtransformations` and + respective instances of :ref:`NXcoordinate_system`. Especially when this + NXinstrument_em base class is used in an application definition like NXem. + + + + Discouraged free-text field to provide details about how to interpret rotation. + + + + + + The interpretation of these position values can be contextualized via the comment + attribute. However, it is better to describe the reference frame in which the + position values are defined explicitly using instances of :ref:`NXtransformations` + and respective instances of :ref:`NXcoordinate_system`. Especially when this + NXinstrument_em base class is used in an application definition like NXem. + + + + + + + + + In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically + frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and + relocated portions of the specimen that have been cut off during site-specific lift-outs + and specimen preparation. + + + + + Gas injection systems (GIS) are components of microscopes that are equipped with focused-ion beam + capabilities. The component is used to introduce reactive neutral gases to the sample surface for + enhanced etching, preferential etching, or material deposition. + + + + + + diff --git a/base_classes/NXinteraction_volume_em.nxdl.xml b/base_classes/NXinteraction_volume_em.nxdl.xml new file mode 100644 index 0000000000..f7ba212c79 --- /dev/null +++ b/base_classes/NXinteraction_volume_em.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Base class to describe the volume of interaction for particle-matter interaction. + + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle-resolved sets of trajectories. + + Explicit or implicit descriptions of the geometry of this + interaction volume 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 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 flux through + an imaginary control surface (the iso-surface) 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>`_ + * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ + + + + diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml new file mode 100644 index 0000000000..f40401df37 --- /dev/null +++ b/base_classes/NXoptical_system_em.nxdl.xml @@ -0,0 +1,164 @@ + + + + + + Base class for qualifying an electron optical system. + + + + Distance which is present between the specimen surface and the detector plane. + + This concept is related to term `Camera Length`_ of the EMglossary standard. + + .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 + + + + + The factor of enlargement of the apparent size, + not the physical size, of an object. + + + + + The defocus aberration constant (oftentimes referred to as c_1_0). + See respective details in :ref:`NXaberration` class instances. + + + + + The angle which is given by the semi-opening angle of the cone in a convergent + beam. + + This concept is related to term `Convergence Angle`_ of the EMglossary standard. + + .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Distance which is determined along the optical axis within the column from (1) the + lower end of the final optical element between the source and the specimen stage; + to (2) the point where the beam is focused. + + This concept is related to term `Working Distance`_ of the EMglossary standard. + + .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 + + + + + + Geometry of the cross-section formed when the primary beam shines onto the + specimen surface. Reported as length of the semiaxes of the ellipsoidal + cross-section with semiaxes values sorted by decreasing length. + + + + + + + + + Electrical current which arrives at the specimen. + + This concept is related to term `Probe Current`_ of the EMglossary standard. + + .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 + + + + + Specify further details how incipient electron or ion dose was quantified + (using beam_current, probe_current). + + `Reference <https://doi.org/10.1017/S1551929522000840>`_ discusses + an approach for (electron) dose monitoring in an electron microscope. + + The unit of the nominal dose rate is e-/(angstrom^2*s). + + + + + Nominal dose rate. + + + + + In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated + on a helical path about the optical axis. This causes an image rotation whose strength + is affected by the magnification. + + Microscopes may be equipped with compensation methods (implemented in hardware + or software) that reduce but not necessarily eliminate this rotation. + + See `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ for details. + + + + + Distance which lies between the principal plane of the lens and the focal point + along the optical axis. + + This concept is related to term `Focal Length`_ of the EMglossary standard. + + .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 + + + + + Details about an imaging setting used during acquisition to correct perspective + distortion when imaging a tilted surface or cross section. + + This concept is related to term `Tilt Correction`_ of the EMglossary standard. + + .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 + + + + + Details about a dynamic focus correction used. + + This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. + + .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 + + + + + Details about a workflow used to keep the specimen in focus by automatic means. + + This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. + + .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 + + + diff --git a/base_classes/NXphase.nxdl.xml b/base_classes/NXphase.nxdl.xml new file mode 100644 index 0000000000..8f6891a3f0 --- /dev/null +++ b/base_classes/NXphase.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + Base class to describe a (thermodynamic) phase as a component of a material. + + Instances of phases can be crystalline. + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model (no sufficiently significant information available). + In other words, the phase_name is n/a aka notIndexed. + + The identifier_phase value should match with the integer suffix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if three phases were used e.g. 0, 1, and 2, three instances of + :ref:`NXphase` named phase0, phase1, and phase2 should be stored + in that HDF5 file. + + + + + Given name as an alias for identifying this phase. + + If the identifier_phase is 0 and one would like to use + the field name, the value should be n/a or notIndexed. + + + + + + diff --git a/base_classes/NXrotations.nxdl.xml b/base_classes/NXrotations.nxdl.xml new file mode 100644 index 0000000000..f931ac2591 --- /dev/null +++ b/base_classes/NXrotations.nxdl.xml @@ -0,0 +1,244 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of value tuples. + + + + + How many phases with usually different crystal and symmetry are distinguished. + + + + + + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ + * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ + * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ + * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ + + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + + The concepts of mis- and disorientation are relevant when analyzing the + crystallography of interfaces. + + + + Reference to an instance of :ref:`NXcoordinate_system` which contextualizes + how the here reported parameterized quantities can be interpreted. + + + + + Point group which defines the symmetry of the crystal. + + This has to be at least a single string. If crystal_symmetry is not + provided, point group 1 is assumed. + + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field needs to encode two strings: + The first string is for phase A. The second string is for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + + + + + + + + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided, point group 1 is assumed. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, have become obsolete thanks + to improvements in methods, software, and available computing power. + + Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed, and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description should be avoided. + + + + + + + + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. + + + + + + + + + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many possible + Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + + + + + + + + The set of orientations expressed in quaternion parameterization and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations with the antipodal property. + + + + + + + + + The set of orientations expressed in Euler angle parameterization following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + The set of misorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + The misorientation should not be confused with the disorientation, + as for the latter the angular argument is expected to be the minimal + obeying symmetries. + + + + + + + + + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + + + + + + + + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + + + + + + + + + + The set of disorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent disorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Disorientations angular argument (should not be signed, see + `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + + + + + + + + Disorientations axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_angle. + + + + + + + diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..0fc0dce988 --- /dev/null +++ b/base_classes/NXscanbox_em.nxdl.xml @@ -0,0 +1,81 @@ + + + + + + The scan box or scan controller is a component that is used to deflect a + beam of charged particles in a controlled manner. + + The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, + which is not necessarily the same program as the one controlling other parts of the instrument. + + The scanbox directs the probe of charged particles (electrons, ions) + to controlled locations according to a scan scheme and plan. + + + + + Name of the typically tech-partner-specific term that specifies an + automated protocol which details how the components of the scan_box + and the instrument work together to achieve a controlled + scanning of the beam (over the sample surface). + + Oftentimes users do not need to or are not able to disentangle the intricate + details of the spatiotemporal dynamics of their instrument. Instead, often + they rely on the assumption that the instrument and its controlling programs + work as expected. The field scan_schema can be used to add some constraints + on how the beam was scanned over the surface. + + + + + + Time period during which the beam remains at one position. + + This concept is related to term `Dwell Time`_ of the EMglossary standard. + + .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 + + + + + Time period during which the beam moves from the final position of one scan + line to the starting position of the subsequent scan line. + + This concept is related to term `Flyback Time`_ of the EMglossary standard. + + .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 + + + + + + Details about components which realize the deflection technically. + + This concept should be used for all those components that implement + the scanning of the beam, while components like beam blankers etc. should + use rather the NXdeflector concept of the NXebeam_column base class. + + + + diff --git a/base_classes/nyaml/NXaberration.yaml b/base_classes/nyaml/NXaberration.yaml new file mode 100644 index 0000000000..29b1343063 --- /dev/null +++ b/base_classes/nyaml/NXaberration.yaml @@ -0,0 +1,122 @@ +category: base +doc: | + Quantified aberration coefficient in an aberration_model. + + For an introduction in the aberrations in electron microscopy + see `R. Dunin-Borkowski et al. `_ and + `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. + Conversion tables are also summarized by `Y. Liao `_ an introduction. +type: group +NXaberration(NXobject): + magnitude(NX_NUMBER): + unit: NX_ANY + doc: | + Magnitude of the aberration + magnitude_errors(NX_NUMBER): + unit: NX_ANY + doc: | + Uncertainty of the magnitude of the aberration + magnitude_errors_model(NX_CHAR): + doc: | + Free-text description how magnitude_errors was quantified + e.g. via the 95% confidence interval, variance, standard deviation, + using which algorithm or statistical model. + delta_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time elapsed since the last measurement. + angle(NX_NUMBER): + unit: NX_ANGLE + 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. + name(NX_CHAR): + doc: | + Given name to this aberration. + alias(NX_CHAR): + doc: | + Alias to name or refer to this specific type of aberration. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 56e233c76debb9af5eff7325e0624f51d50b71e6153718e5ecd01d30bae025b3 +# +# +# +# +# +# Quantified aberration coefficient in an aberration_model. +# +# For an introduction in the aberrations in electron microscopy +# see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and +# `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. +# Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. +# +# +# +# Magnitude of the aberration +# +# +# +# +# Uncertainty of the magnitude of the aberration +# +# +# +# +# Free-text description how magnitude_errors was quantified +# e.g. via the 95% confidence interval, variance, standard deviation, +# using which algorithm or statistical model. +# +# +# +# +# Time elapsed since the last measurement. +# +# +# +# +# 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. +# +# +# +# +# Given name to this aberration. +# +# +# +# +# Alias to name or refer to this specific type of aberration. +# +# +# diff --git a/base_classes/nyaml/NXcorrector_cs.yaml b/base_classes/nyaml/NXcorrector_cs.yaml new file mode 100644 index 0000000000..cec7902e3d --- /dev/null +++ b/base_classes/nyaml/NXcorrector_cs.yaml @@ -0,0 +1,303 @@ +category: base +doc: | + Base class for a corrector reducing (spherical) aberrations in electron microscopy. + + Different technology partners use different conventions and + models for quantifying the aberration coefficients. + + Correctors in an electron microscope are composed of multiple lenses + and multipole stigmators. Their technical details are specific for the + technology partner as well as microscope. Most technical details are + proprietary knowledge. + + If one component corrects for multiple types of aberrations (like it is the case + reported here `CEOS `_) follow this + design when using corrector and monochromator in an application definition: + + * Use :ref:`NXcorrector_cs` for spherical aberration + * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration + * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_img: | + Number of images taken, at least one. +type: group +NXcorrector_cs(NXcomponent): + + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + tableauID(NXprocess): + nameType: partial + doc: | + Specific information about the alignment procedure. This is a process during which + the corrector is configured to enable calibrated usage of the instrument. + + This :ref:`NXprocess` group should also be used when one describes in a computer + simulation the specific details about the modelled or assumed aberrations. + description(NX_CHAR): + doc: | + Discouraged free-text field to add further details about the alignment + procedure. + tilt_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + The outer tilt angle of the beam in tableau acquisition. + + TODO: The relevant axes which span the tilt_angle need a + cleaner description. Suggestions from the community are + welcome here for guiding an improvement of this base class. + dimensions: + rank: 1 + dim: (n_img,) + exposure_time(NX_NUMBER): + unit: NX_TIME + doc: | + The exposure time of single tilt images. + dimensions: + rank: 1 + dim: (n_img,) + magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The factor of enlargement of the apparent size, + not the physical size, of an object. + dimensions: + rank: 1 + dim: (n_img,) + imageID(NXimage): + nameType: partial + doc: | + Image(s) taken during the alignment procedure + model(NX_CHAR): + doc: | + Convention used for storing measured or estimated aberrations (for each or the final image) + via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. + + 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. Conversion tables are also summarized by `Y. Liao `_. + enumeration: [ceos, nion] + + # specifically-named aberrations following the CEOS / Typke and Dierksen convention + c_1(NXaberration): + a_1(NXaberration): + b_2(NXaberration): + a_2(NXaberration): + c_3(NXaberration): + s_3(NXaberration): + a_3(NXaberration): + + # based on feedback from Thilo Remmele the following aberrations could be measured + # (enhanced mode, tilt angle > 30 mrad) but are not corrected for with + b_4(NXaberration): + d_4(NXaberration): + a_4(NXaberration): + c_5(NXaberration): + s_5(NXaberration): + r_5(NXaberration): + a_6(NXaberration): + + # specifically-named aberrations following the Nion convention + c_1_0(NXaberration): + c_1_2_a(NXaberration): + c_1_2_b(NXaberration): + c_2_1_a(NXaberration): + c_2_1_b(NXaberration): + c_2_3_a(NXaberration): + c_2_3_b(NXaberration): + c_3_0(NXaberration): + c_3_2_a(NXaberration): + c_3_2_b(NXaberration): + c_3_4_a(NXaberration): + c_3_4_b(NXaberration): + c_4_1_a(NXaberration): + c_4_1_b(NXaberration): + c_4_3_a(NXaberration): + c_4_3_b(NXaberration): + c_4_5_a(NXaberration): + c_4_5_b(NXaberration): + c_5_0(NXaberration): + c_5_2_a(NXaberration): + c_5_2_b(NXaberration): + c_5_4_a(NXaberration): + c_5_4_b(NXaberration): + c_5_6_a(NXaberration): + c_5_6_b(NXaberration): + (NXlens_em): + (NXaperture): + (NXdeflector): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6058db5121e6633ea3ec355f79d43ab1ee54bf298dd8945d3f0746dd51a5af33 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of images taken, at least one. +# +# +# +# +# Base class for a corrector reducing (spherical) aberrations in electron microscopy. +# +# Different technology partners use different conventions and +# models for quantifying the aberration coefficients. +# +# Correctors in an electron microscope are composed of multiple lenses +# and multipole stigmators. Their technical details are specific for the +# technology partner as well as microscope. Most technical details are +# proprietary knowledge. +# +# If one component corrects for multiple types of aberrations (like it is the case +# reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this +# design when using corrector and monochromator in an application definition: +# +# * Use :ref:`NXcorrector_cs` for spherical aberration +# * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration +# * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration +# +# +# +# +# Was the corrector used? +# +# +# +# +# Specific information about the alignment procedure. This is a process during which +# the corrector is configured to enable calibrated usage of the instrument. +# +# This :ref:`NXprocess` group should also be used when one describes in a computer +# simulation the specific details about the modelled or assumed aberrations. +# +# +# +# Discouraged free-text field to add further details about the alignment +# procedure. +# +# +# +# +# The outer tilt angle of the beam in tableau acquisition. +# +# TODO: The relevant axes which span the tilt_angle need a +# cleaner description. Suggestions from the community are +# welcome here for guiding an improvement of this base class. +# +# +# +# +# +# +# +# The exposure time of single tilt images. +# +# +# +# +# +# +# +# The factor of enlargement of the apparent size, +# not the physical size, of an object. +# +# +# +# +# +# +# +# Image(s) taken during the alignment procedure +# +# +# +# +# Convention used for storing measured or estimated aberrations (for each or the final image) +# via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. +# +# 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. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcs_profiling.yaml b/base_classes/nyaml/NXcs_profiling.yaml index 05e47e8a7c..54de8679ac 100644 --- a/base_classes/nyaml/NXcs_profiling.yaml +++ b/base_classes/nyaml/NXcs_profiling.yaml @@ -13,7 +13,7 @@ doc: | information across a network and these are used usually by multiple users. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software i.e. an app took. + analysis with a scientific software, i.e. an app took. A frequent idea is here to answer practical questions like how critical is the effect on the workflow of the scientists, i.e. is the analysis possible in a few seconds or would it take days if I were to run this analysis on a @@ -113,7 +113,7 @@ NXcs_profiling(NXobject): # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8f7d0b74d0f964836e56f866e550b56f28e0972dc6914ebec8b7dfe37dd5192f +# f183e7426e1ed93a852853d9be7400e1b56ff86050fea6459941c8d3b75891d5 # # # +# +# +# Base class for a set of components providing a controllable electron beam. +# +# The idea behind defining NXebeam_column as an own base class vs. adding these +# concepts in NXinstrument_em is that the electron beam generating component +# might be worthwhile to use also in other types of experiments. +# +# +# +# Tech-partner, microscope-, and control-software-specific name of the +# specific operation mode how the ebeam_column and its components are +# controlled to achieve specific illumination conditions. +# +# In many cases the users of an instrument do not or can not be expected to know +# all intricate spatiotemporal dynamics of their hardware. Instead, they rely on +# assumptions that the instrument, its control software, and components work as +# expected to focus on their research questions. +# +# For these cases, having a place for documenting the operation_mode is useful +# in as much as at least some constraints on how the illumination conditions were +# is documented. +# +# +# +# +# A physical part of an electron or ion microscope from which +# the particles that form the beam are emitted. +# +# The hardware for an electron source in an electron microscope +# may contain several components which affect the beam path. +# +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# +# +# +# The potential difference between anode and cathode. +# +# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. +# +# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 +# +# +# +# +# Voltage which is used to create an electric field that draws particles from +# the source. +# +# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. +# +# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which is released from the source. +# +# This concept is related to term `Emission Current`_ of the EMglossary standard. +# +# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which flows through the source. +# +# This concept is related to term `Filament Current`_ of the EMglossary standard. +# +# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 +# +# +# +# +# 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. +# +# +# +# +# +# How long has the source been in operation. +# +# +# +# +# +# +# +# +# A component for blanking the beam or generating pulsed electron beams. +# See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ +# or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. +# +# +# +# +# Device to improve energy resolution or chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# +# +# +# +# Qualitative type of the component. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Was the corrector used? +# +# +# +# +# +# Energy dispersion in e.g. µm/eV. +# +# +# +# +# Corresponding voltage for that energy dispersion. +# +# +# +# +# +# +# Component that reshapes an ellipse-shaped electron beam into a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. +# +# +# +# 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 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 users. +# +# +# +# +# +# Electron biprism as it is used e.g. for electron holography. +# +# +# +# +# Device that causes a change in the phase of an electron wave. +# +# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ +# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ +# +# +# +# Qualitative type +# +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the electron beam at a given location. +# +# :ref:`NXtransformations` should be used to specify the location +# or the position at which details about the beam were probed. +# +# This concept is related to term `Electron Beam`_ of the EMglossary standard. +# +# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 +# +# +# +# +# diff --git a/base_classes/nyaml/NXem_ebsd.yaml b/base_classes/nyaml/NXem_ebsd.yaml new file mode 100644 index 0000000000..4074e3c9ed --- /dev/null +++ b/base_classes/nyaml/NXem_ebsd.yaml @@ -0,0 +1,1178 @@ +category: base +doc: +- | + Base class method-specific for Electron Backscatter Diffraction (EBSD). +- | + The general procedure of an EBSD experiment is as follows: + Users load the specimen, collect first a coarse image of the surface. + Next, they set an approximate value for the calibrated working distance + and tilt the stage into diffraction conditions. +- | + Users then typically configure the microscope for collecting quality data. + The EBSD detector is pushed in (if retractable). Subsequently, they fine tune + the illumination and aberration corrector settings and select one or multiple ROIs + for the microscope to machine off automatically. They configure on-the-fly + indexing parameter and then typically start the measurement queue. + From this point onwards typically the microscope runs automatically. +- | + Diffraction pattern get collected until the queue finishes or gets interrupted by + either errors or arrival at the end of the users' allocated timeslot at the instrument. +- | + Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. + Once indexed, these patterns are often not stored. +- | + Results are stored in files, which afterwards are typically copied + automatically or manually for archival purposes to certain storage + locations for further consumption. The result of such an EBSD + measurement/experiment is a set of usually proprietary or open files + from technology partners. +- | + This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific + data, metadata, and connections between these for the research field of + electron microscopy exemplified here for electron backscatter diffraction (EBSD). + The base class solves two key documentation issues within the EBSD community: +- | + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted + according to NXem_ebsd) stores the connection between the microscope session and + the key datasets which are considered typically results of the afore-mentioned + steps involved in an EBSD experiment. +- | + Different groups in NXem_ebsd make connections to data artifacts which were collected + when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, + associated overview images, like secondary electron or backscattered electron + images of the region-of-interest probed, and many more (meta)data. +- | + Secondly, NXem_ebsd connects and stores the conventions and reference frames + which were used and which are the key to a correct mathematical interpretation + of every experiment or simulation using EBSD. +- | + Otherwise, results would be ripped out of their context like it is the current situation + with many traditional studies where EBSD data were indexed on-the-fly and shared + with the community only via sharing the strongly processed files with results in some + formatting but without communicating all conventions used or just relying on the assumptions + that colleagues likely know these conventions even though + multiple definitions are possible. +- | + NXem_ebsd 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) experiments + where a combination of repetitive removal of material from the surface layer to measure + otherwise the same region-of-interest at different depth increments. Material removal + can be achieved with mechanical, electron, or ion polishing, using manual steps or + automated equipment like a robot system `S. Tsai et al. `_. +- | + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By virtue of design, these methods are destructive + either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. +- | + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these images are indexed to process + a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint + also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. +- | + xref: + spec: EMglossary + term: Electron Backscatter Diffraction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 +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 plot orientation mapping. + n_y: | + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. + n_x: | + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. + n_solutions: | + Number of phase solutions + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). +type: group +NXem_ebsd(NXprocess): + gnomonic_reference_frame(NXcoordinate_system): + doc: | + Details about the gnomonic (projection) reference frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions are not met, the user is required to explicitly state this. + + Reference ``_ suggests to label the + base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. + origin(NX_CHAR): + doc: | + Origin of the gnomonic_reference_frame. + + Reference ``_ suggests to + assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. + enumeration: [in_the_pattern_center] + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of the + gnomonic_reference_frame. + enumeration: [north, east, south, west, in, out] + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of the + gnomonic_reference_frame. + enumeration: [north, east, south, west, in, out] + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of the + gnomonic_reference_frame. + enumeration: [north, east, south, west, in, out] + pattern_center(NXprocess): + doc: | + Details about the definition of the pattern center as a special point in the + gnomonic_reference_frame. + + Typically the gnomonic space is embedded in the detector space. + Specifically, the XgYg plane is defined such that it is 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 + one effectively normalizes in fractions of the width of the detector. + + The issue with terms like width and height, though, is that these become degenerated + if the detector region-of-interest is square-shaped. This is why instead of referring to + width and height it is better to state explicitly which direction is considered positive + when measuring distances. + + For the concepts used to specify the boundary_convention it is assumed that the + region-of-interest is defined by a rectangle, referring to the direction of outer-unit + normals to the respective edges of this rectangle. + x_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference frame) is the pattern + center's x-position (PCx) measured. + enumeration: [top, right, bottom, left] + x_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for the x-axis coordinate value measured + from the specified boundary. + enumeration: [north, east, south, west] + y_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference frame) is the pattern + center's y-position (PCy) measured. + enumeration: [top, right, bottom, left] + y_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for the y-axis coordinate value measured + from the specified boundary. + enumeration: [north, east, south, west] + measurement(NXprocess): + doc: | + This group documents relevant details about the conditions and the + tools for measuring diffraction patterns with an electron microscope. + + The most frequently collected EBSD data are captured for rectangular + regions-of-interest using a discretization into square or hexagon tiles. + time(NX_NUMBER): + unit: NX_TIME + doc: | + Physical time since the beginning of a timestamp that is required to be + the same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set need 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, + 30 minutes, 6 hours, or 24 hours of annealing. + \@epoch_start(NX_CHAR): + doc: | + Timestamp relative to which time was counted to aid + converting between time and timestamp. + depends_on(NX_CHAR): + doc: | + Path to an instance of :ref:`NXdata` where the measured patterns are stored. + source(NXnote): + doc: | + Reference (e.g. path and filename) to an existent data artifact which + stores either the measured patterns or input (already processed EBSD data). + simulation(NXprocess): + doc: | + This group documents relevant details about the conditions and the tools + used for simulating diffraction patterns with some physical model. + + This group should be used if (e.g. instead of a measurement) the patterns + were simulated (possibly awaiting indexing). + + In many practical cases where patterns are analyzed on-the-fly and dictionary + indexing strategies used, so-called master pattern(s) are used to compare + measured or simulated patterns with the master patterns. + depends_on(NX_CHAR): + doc: | + Path to an instance of :ref:`NXimage` where the simulated patterns are stored. + source(NXnote): + doc: | + Reference (e.g. path and filename) to an existent digital resource which + stores either the patterns or input (already processed EBSD data) that are + about to become processed further as described by this NXem_ebsd instance. + calibration(NXprocess): + doc: | + The EBSD system, including components like the electron gun, pole-piece, + stage tilt, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable, precise, and accurate scientific results. + + Specifically, the gnomonic projection has to be calibrated. + Typically, standard specimens made from silicon or quartz crystals + in specific orientations are used for this purpose. + + Considering that a system used is already calibrated well-enough is much + more frequently the case in practice than that users perform the calibration + themselves (with above-mentioned standard specimens). + + 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 has been calibrated already. Consequently, users pick from + an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. + Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). + + In the second case, users calibrate the system during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how the + reference frames are configured and how this setup in the GUI. + + 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' obligation to remember these + settings or write these down in a lab notebook. Otherwise, these metadata + get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` + solves in that all conventions can be specified explicitly. + depends_on(NX_CHAR): + doc: | + Path to an instance of :ref:`NXem` where calibration data are stored. + source(NXnote): + doc: | + Reference to a digital resource where the calibration is stored. + indexing(NXprocess): + doc: | + Indexing is a data processing step performed either after or while (aka on-the-fly) + the beam scans the specimen. The resulting method is also + known as orientation imaging microscopy (OIM). + + Different algorithms can be used to index EBSP. Common to them is the + computational step where simulated or theoretically assumed patterns + are compared with the measured ones. These latter patterns are referred + to via the measurement or simulation groups of this base class respectively. + + Quality descriptors are defined based on which an indexing algorithm + yields a quantitative measure of how similar measured and reference + patterns are, and thus if no, one, or multiple so-called solutions were found. + + Assumed or simulated patterns are simulated using kinematical or dynamical + theory of electron diffraction delivering master patterns. + + The Hough transform, one of the most frequently used traditional method for indexing + EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. `_). Recently, dictionary-based and artificial intelligence-based methods + find more widespread usage for indexing. + source(NXnote): + doc: | + This group enables to establish a logical connection between previous + processing steps or on-the-fly-performed indexing of the EBSD map. + Typically these processing steps are performed with commercial software. + Therefore, in many cases a results file from this indexing is often + all that is communicated and saved. These are typically files in a format + specific to the instrument and its configuration. + + Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. + method(NX_CHAR): + doc: | + Principal algorithm used for indexing. + enumeration: + open_enum: true + items: [hough_transform, dictionary, radon_transform] + background_correction(NXprocess): + doc: | + Details about the background correction applied to each Kikuchi pattern. + binning(NXprocess): + doc: | + Binning i.e. downsampling to each pattern. + parameter(NXcollection): + doc: | + Specific parameter relevant only for certain algorithms used. + phaseID(NXphase): + nameType: partial + doc: | + Details for each phase used as a model with which the patterns were + indexed. Instances of :ref:`NXunit_cell` in this group must + have the group name prefixed with phase. The identifier in the name is an + integer. Start counting from 1 because the value 0 is reserved for + the special phase that is the null-model, the null phase also known + as notIndexed. + dspacing(NX_NUMBER): + unit: NX_LENGTH + doc: | + Spacing between the crystallographic planes that are defined via ``miller``. + dimensions: + rank: 1 + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Relative intensity for the computed diffraction intensity (signal) for the + plane. + dimensions: + rank: 1 + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + unit: NX_UNITLESS + doc: | + In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps + this field stores how many scan points of the map were identified as matching best + with this phase. + number_of_planes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many reflectors for crystallographic planes are distinguished. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. + dimensions: + rank: 2 + dim: (n_hkl, 6) + status(NX_UINT): + unit: NX_UNITLESS + doc: | + Which return value did the indexing algorithm yield for each scan point. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + dimensions: + rank: 1 + dim: (n_sc,) + phases_per_scan_point(NX_INT): + unit: NX_UNITLESS + 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 :ref:`NXunit_cell`. + + In another example users may have skipped some scan points (not indexed + them at all) or used differing numbers of phases for indexing different scan points. + + The cumulated of this array decodes how identifier_phase and matching_phase + 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), + identifier_phase has as many entries as scan points + and matching_phase has also as many entries as scan points. + dimensions: + rank: 1 + dim: (n_sc,) + identifier_phase(NX_INT): + unit: NX_UNITLESS + doc: | + The array phases_per_scan_point details how the identifier_phase + and the matching_phase arrays have to be interpreted. + + For the example with a single phase identifier_phase 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 + required) that a pattern matches eventually (not equally well) sufficiently + significant with multiple patterns. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models. Having such field is especially relevant + for recent dictionary- or artificial intelligence-based indexing methods to communicate + the results in a model-agnostic way in combination with matching_phase. + + Depending on the phases_per_scan_point value, identifier_phase and + matching_phase arrays represent a collection of concatenated tuples. + These 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 phases_per_scan_point. + dimensions: + rank: 1 + dim: (n_solutions,) + matching_phase(NX_INT): + unit: NX_UNITLESS + doc: | + One-dimensional array, pattern by pattern labelling the solutions found. + The array phases_per_scan_point has to be specified because it details + how the identifier_phase and the matching_phase arrays are interpreted. + See documentation of identifier_phase for further details. + dimensions: + rank: 1 + dim: (n_solutions,) + matching_phase_descriptor(NX_CHAR): + doc: | + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence_index, mean_angular_deviation, or other. + enumeration: [confidence_index, mean_angular_deviation, other] + rotation(NXrotations): + scan_point_positions(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center positions of each scan point + in the sample surface reference system. + dimensions: + rank: 2 + dim: (n_sc, 2) + indexing_rate(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Fraction of successfully indexed patterns with a phase + not the null-phase vs the number_of_scan_points. + number_of_scan_points(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of scan points in the original mapping. + + # + # + # + # + roi(NXdata): + doc: | + An overview of the entire ROI. + descriptor(NX_CHAR): + doc: | + Descriptor representing the image contrast. + enumeration: [band_contrast, confidence_index, mean_angular_deviation] + title(NX_CHAR): + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dimensions: + rank: 2 + dim: (n_y, n_x) + \@long_name(NX_CHAR): + doc: | + Descriptor values + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dimensions: + rank: 1 + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dimensions: + rank: 1 + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Label for the x axis + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 82a3639815330347d1689d9057a7881b35944b189b49d76b005137bc07062ade +# +# +# +# +# +# +# +# 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 plot orientation mapping. +# +# +# +# +# Number of pixel along slow changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of pixel along fast changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of phase solutions +# +# +# +# +# Number of reflectors (Miller crystallographic plane triplets). +# +# +# +# +# Base class method-specific for Electron Backscatter Diffraction (EBSD). +# +# The general procedure of an EBSD experiment is as follows: +# Users load the specimen, collect first a coarse image of the surface. +# Next, they set an approximate value for the calibrated working distance +# and tilt the stage into diffraction conditions. +# +# Users then typically configure the microscope for collecting quality data. +# The EBSD detector is pushed in (if retractable). Subsequently, they fine tune +# the illumination and aberration corrector settings and select one or multiple ROIs +# for the microscope to machine off automatically. They configure on-the-fly +# indexing parameter and then typically start the measurement queue. +# From this point onwards typically the microscope runs automatically. +# +# Diffraction pattern get collected until the queue finishes or gets interrupted by +# either errors or arrival at the end of the users' allocated timeslot at the instrument. +# +# Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. +# Once indexed, these patterns are often not stored. +# +# Results are stored in files, which afterwards are typically copied +# automatically or manually for archival purposes to certain storage +# locations for further consumption. The result of such an EBSD +# measurement/experiment is a set of usually proprietary or open files +# from technology partners. +# +# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific +# data, metadata, and connections between these for the research field of +# electron microscopy exemplified here for electron backscatter diffraction (EBSD). +# The base class solves two key documentation issues within the EBSD community: +# +# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted +# according to NXem_ebsd) stores the connection between the microscope session and +# the key datasets which are considered typically results of the afore-mentioned +# steps involved in an EBSD experiment. +# +# Different groups in NXem_ebsd make connections to data artifacts which were collected +# when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, +# associated overview images, like secondary electron or backscattered electron +# images of the region-of-interest probed, and many more (meta)data. +# +# Secondly, NXem_ebsd connects and stores the conventions and reference frames +# which were used and which are the key to a correct mathematical interpretation +# of every experiment or simulation using EBSD. +# +# Otherwise, results would be ripped out of their context like it is the current situation +# with many traditional studies where EBSD data were indexed on-the-fly and shared +# with the community only via sharing the strongly processed files with results in some +# formatting but without communicating all conventions used or just relying on the assumptions +# that colleagues likely know these conventions even though +# multiple definitions are possible. +# +# NXem_ebsd 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) experiments +# where a combination of repetitive removal of material from the surface layer to measure +# otherwise the same region-of-interest at different depth increments. Material removal +# can be achieved with mechanical, electron, or ion polishing, using manual steps or +# automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. +# +# Three-dimensional experiments require to follow a sequence of specimen, surface +# preparation, and data collection steps. By virtue of design, these methods are destructive +# either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. +# +# Eventual tomography methods also use such a workflow because first diffraction +# images are collected (e.g. with X-ray) and then these images are indexed to process +# a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint +# also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. +# +# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. +# +# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 +# +# +# +# Details about the gnomonic (projection) reference frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions are not met, the user is required to explicitly state this. +# +# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the +# base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. +# +# +# +# Origin of the gnomonic_reference_frame. +# +# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to +# assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the definition of the pattern center as a special point in the +# gnomonic_reference_frame. +# +# Typically the gnomonic space is embedded in the detector space. +# Specifically, the XgYg plane is defined such that it is 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 +# one effectively normalizes in fractions of the width of the detector. +# +# The issue with terms like width and height, though, is that these become degenerated +# if the detector region-of-interest is square-shaped. This is why instead of referring to +# width and height it is better to state explicitly which direction is considered positive +# when measuring distances. +# +# For the concepts used to specify the boundary_convention it is assumed that the +# region-of-interest is defined by a rectangle, referring to the direction of outer-unit +# normals to the respective edges of this rectangle. +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# center's x-position (PCx) measured. +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the x-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# center's y-position (PCy) measured. +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the y-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# +# This group documents relevant details about the conditions and the +# tools for measuring diffraction patterns with an electron microscope. +# +# The most frequently collected EBSD data are captured for rectangular +# regions-of-interest using a discretization into square or hexagon tiles. +# +# +# +# Physical time since the beginning of a timestamp that is required to be +# the same for all experiments in the set. The purpose of this marker is +# to identify how all experiments in the set need 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, +# 30 minutes, 6 hours, or 24 hours of annealing. +# +# +# +# Timestamp relative to which time was counted to aid +# converting between time and timestamp. +# +# +# +# +# +# Path to an instance of :ref:`NXdata` where the measured patterns are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent data artifact which +# stores either the measured patterns or input (already processed EBSD data). +# +# +# +# +# +# This group documents relevant details about the conditions and the tools +# used for simulating diffraction patterns with some physical model. +# +# This group should be used if (e.g. instead of a measurement) the patterns +# were simulated (possibly awaiting indexing). +# +# In many practical cases where patterns are analyzed on-the-fly and dictionary +# indexing strategies used, so-called master pattern(s) are used to compare +# measured or simulated patterns with the master patterns. +# +# +# +# Path to an instance of :ref:`NXimage` where the simulated patterns are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent digital resource which +# stores either the patterns or input (already processed EBSD data) that are +# about to become processed further as described by this NXem_ebsd instance. +# +# +# +# +# +# The EBSD system, including components like the electron gun, pole-piece, +# stage tilt, EBSD detector, and the gnomonic projection have to be +# calibrated to achieve reliable, precise, and accurate scientific results. +# +# Specifically, the gnomonic projection has to be calibrated. +# Typically, standard specimens made from silicon or quartz crystals +# in specific orientations are used for this purpose. +# +# Considering that a system used is already calibrated well-enough is much +# more frequently the case in practice than that users perform the calibration +# themselves (with above-mentioned standard specimens). +# +# 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 has been calibrated already. Consequently, users pick from +# an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. +# Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). +# +# In the second case, users calibrate the system during the session +# using standards (silicon, quartz, or other common specimens). +# There is usually one person in each lab responsible for doing such +# calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, +# the conventions how orientations are stored is affected by how the +# reference frames are configured and how this setup in the GUI. +# +# 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' obligation to remember these +# settings or write these down in a lab notebook. Otherwise, these metadata +# get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` +# solves in that all conventions can be specified explicitly. +# +# +# +# Path to an instance of :ref:`NXem` where calibration data are stored. +# +# +# +# +# Reference to a digital resource where the calibration is stored. +# +# +# +# +# +# Indexing is a data processing step performed either after or while (aka on-the-fly) +# the beam scans the specimen. The resulting method is also +# known as orientation imaging microscopy (OIM). +# +# Different algorithms can be used to index EBSP. Common to them is the +# computational step where simulated or theoretically assumed patterns +# are compared with the measured ones. These latter patterns are referred +# to via the measurement or simulation groups of this base class respectively. +# +# Quality descriptors are defined based on which an indexing algorithm +# yields a quantitative measure of how similar measured and reference +# patterns are, and thus if no, one, or multiple so-called solutions were found. +# +# Assumed or simulated patterns are simulated using kinematical or dynamical +# theory of electron diffraction delivering master patterns. +# +# The Hough transform, one of the most frequently used traditional method for indexing +# EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods +# find more widespread usage for indexing. +# +# +# +# This group enables to establish a logical connection between previous +# processing steps or on-the-fly-performed indexing of the EBSD map. +# Typically these processing steps are performed with commercial software. +# Therefore, in many cases a results file from this indexing is often +# all that is communicated and saved. These are typically files in a format +# specific to the instrument and its configuration. +# +# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. +# +# +# +# +# Principal algorithm used for indexing. +# +# +# +# +# +# +# +# +# +# Details about the background correction applied to each Kikuchi pattern. +# +# +# +# +# Binning i.e. downsampling to each pattern. +# +# +# +# +# Specific parameter relevant only for certain algorithms used. +# +# +# +# +# Details for each phase used as a model with which the patterns were +# indexed. Instances of :ref:`NXunit_cell` in this group must +# have the group name prefixed with phase. The identifier in the name is an +# integer. Start counting from 1 because the value 0 is reserved for +# the special phase that is the null-model, the null phase also known +# as notIndexed. +# +# +# +# Spacing between the crystallographic planes that are defined via ``miller``. +# +# +# +# +# +# +# +# Relative intensity for the computed diffraction intensity (signal) for the +# plane. +# +# +# +# +# +# +# +# In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps +# this field stores how many scan points of the map were identified as matching best +# with this phase. +# +# +# +# +# How many reflectors for crystallographic planes are distinguished. +# +# +# +# +# Miller indices :math:`(hkl)[uvw]` of the planes. +# +# The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. +# Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. +# +# +# +# +# +# +# +# +# +# Which return value did the indexing algorithm yield for each scan point. +# +# * 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 :ref:`NXunit_cell`. +# +# In another example users may have skipped some scan points (not indexed +# them at all) or used differing numbers of phases for indexing different scan points. +# +# The cumulated of this array decodes how identifier_phase and matching_phase +# 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), +# identifier_phase has as many entries as scan points +# and matching_phase has also as many entries as scan points. +# +# +# +# +# +# +# +# The array phases_per_scan_point details how the identifier_phase +# and the matching_phase arrays have to be interpreted. +# +# For the example with a single phase identifier_phase 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 +# required) that a pattern matches eventually (not equally well) sufficiently +# significant with multiple patterns. This can especially happen in cases of +# pseudosymmetry and more frequently with an improperly calibrated system +# or false or inaccurate phase models. Having such field is especially relevant +# for recent dictionary- or artificial intelligence-based indexing methods to communicate +# the results in a model-agnostic way in combination with matching_phase. +# +# Depending on the phases_per_scan_point value, identifier_phase and +# matching_phase arrays represent a collection of concatenated tuples. +# These 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 phases_per_scan_point. +# +# +# +# +# +# +# +# One-dimensional array, pattern by pattern labelling the solutions found. +# The array phases_per_scan_point has to be specified because it details +# how the identifier_phase and the matching_phase arrays are interpreted. +# See documentation of identifier_phase for further details. +# +# +# +# +# +# +# +# Phase_matching is a descriptor for how well the solution matches or not. +# Examples can be confidence_index, mean_angular_deviation, or other. +# +# +# +# +# +# +# +# +# +# +# Calibrated center positions of each scan point +# in the sample surface reference system. +# +# +# +# +# +# +# +# +# Fraction of successfully indexed patterns with a phase +# not the null-phase vs the number_of_scan_points. +# +# +# +# +# Number of scan points in the original mapping. +# +# +# +# +# +# An overview of the entire ROI. +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# +# +# +# +# Title of the default plot. +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# Descriptor values +# +# +# +# +# +# Calibrated coordinate along the y-axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated coordinate along the x-axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXem_eds.yaml b/base_classes/nyaml/NXem_eds.yaml new file mode 100644 index 0000000000..45c47c50d2 --- /dev/null +++ b/base_classes/nyaml/NXem_eds.yaml @@ -0,0 +1,336 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). + + `IUPAC instead of Siegbahn notation `_ should be used. + + X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental + characterization requires typically a sequence of characterization and preparation of the + surface to expose new surface layer that can be characterized in the next acquisition. + In effect, the resulting three-dimensional elemental information mappings are truly the + result of a correlation and post-processing of several measurements which is the field + of correlative tomographic usage of electron microscopy. +symbols: + n_photon_energy: | + Number of X-ray photon energy (bins) + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected + n_iupac_line_names: | + Number of IUPAC line names +type: group +NXem_eds(NXprocess): + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + summary(NXdata): + doc: | + Accumulated intensity over all pixels of the region-of-interest. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Accumulated counts + dimensions: + rank: 1 + dim: (n_photon_energy,) + \@long_name(NX_CHAR): + doc: | + Counts + axis_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis + dimensions: + rank: 1 + dim: (n_photon_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + atom_types(NX_CHAR): + doc: | + Comma-separated list of symbols for elements from the periodic table that have + been confirmed present by the here reported EDS analysis. + + This field can be used when creating instances of :ref:`NXpeak` is not desired. + However, a collection of instances of NXpeak with individual NXatom + can be used to add isotopic information and other relevant context. + (NXpeak): + doc: | + Details about individual indexed peaks. + (NXatom): + energy_range(NX_NUMBER): + unit: NX_ENERGY + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + dimensions: + rank: 1 + dim: (2,) + energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Theoretical energy of the line according to IUPAC. + iupac_line_name(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 grouped with the same peak. + dimensions: + rank: 1 + dim: (n_iupac_line_names,) + ELEMENT_SPECIFIC_MAP(NXimage): + nameType: any + doc: | + Individual element-specific EDS/EDX/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. + + These element-specific EDS maps are instances of :ref:`NXimage` + that should be named by the element from the atom_types field. + + When signal contributions from several peaks were decomposed + users should ideally use a respective number of NXpeak instances + to give further context about the individual signal contributions + are summarized and shown together, e.g. the combined signal + under the curve of carbon and oxygen. + + In this case specify the processing details use peak and weight. + description(NX_CHAR): + doc: | + Discouraged free-text field to add additional information. + iupac_line_candidates(NX_CHAR): + doc: | + Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that + documents which elements and their specific lines are theoretically located within + the energy_range of the spectrum from which the EDS (element) map was computed. + energy_range(NX_NUMBER): + unit: NX_ENERGY + doc: | + Associated :math:`[e_{min}, e_{max}]` bounds of the energy + range for which spectrum counts were accumulated. + dimensions: + rank: 1 + dim: (2,) + (NXprocess): + peak(NX_CHAR): + doc: | + A list of :ref:`NXpeak` instance names whose X-ray quanta were + accumulated for each pixel to obtain an element-specific + EDS map. + dimensions: + rank: 1 + dim: (n_peaks,) + weight(NX_NUMBER): + unit: NX_UNITLESS + doc: | + A list of weights by how much the intensity of each peak + contributes to the intensity of the EDS map. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3903897979b6ea01fe3d2ffbcfc0642fe9593e9419111b1d5de3f419609f3505 +# +# +# +# +# +# +# +# Number of X-ray photon energy (bins) +# +# +# +# +# Number of identified elements +# +# +# +# +# Number of peaks detected +# +# +# +# +# Number of IUPAC line names +# +# +# +# +# Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). +# +# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. +# +# X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental +# characterization requires typically a sequence of characterization and preparation of the +# surface to expose new surface layer that can be characterized in the next acquisition. +# In effect, the resulting three-dimensional elemental information mappings are truly the +# result of a correlation and post-processing of several measurements which is the field +# of correlative tomographic usage of electron microscopy. +# +# +# +# Details about computational steps how peaks were indexed as elements. +# +# +# +# The program with which the indexing was performed. +# +# +# +# +# Accumulated intensity over all pixels of the region-of-interest. +# +# +# +# Accumulated counts +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Comma-separated list of symbols for elements from the periodic table that have +# been confirmed present by the here reported EDS analysis. +# +# This field can be used when creating instances of :ref:`NXpeak` is not desired. +# However, a collection of instances of NXpeak with individual NXatom +# can be used to add isotopic information and other relevant context. +# +# +# +# +# Details about individual indexed peaks. +# +# +# +# +# Associated lower :math:`[e_{min}, e_{max}]` bounds of the +# energy which is assumed associated with this peak. +# +# +# +# +# +# +# +# Theoretical energy of the line according to IUPAC. +# +# +# +# +# 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 grouped with the same peak. +# +# +# +# +# +# +# +# +# +# Individual element-specific EDS/EDX/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. +# +# These element-specific EDS maps are instances of :ref:`NXimage` +# that should be named by the element from the atom_types field. +# +# When signal contributions from several peaks were decomposed +# users should ideally use a respective number of NXpeak instances +# to give further context about the individual signal contributions +# are summarized and shown together, e.g. the combined signal +# under the curve of carbon and oxygen. +# +# In this case specify the processing details use peak and weight. +# +# +# +# Discouraged free-text field to add additional information. +# +# +# +# +# Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that +# documents which elements and their specific lines are theoretically located within +# the energy_range of the spectrum from which the EDS (element) map was computed. +# +# +# +# +# Associated :math:`[e_{min}, e_{max}]` bounds of the energy +# range for which spectrum counts were accumulated. +# +# +# +# +# +# +# +# +# A list of :ref:`NXpeak` instance names whose X-ray quanta were +# accumulated for each pixel to obtain an element-specific +# EDS map. +# +# +# +# +# +# +# +# A list of weights by how much the intensity of each peak +# contributes to the intensity of the EDS map. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXem_eels.yaml b/base_classes/nyaml/NXem_eels.yaml new file mode 100644 index 0000000000..85c1f2aa24 --- /dev/null +++ b/base_classes/nyaml/NXem_eels.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +type: group +NXem_eels(NXprocess): + zlp_correction(NXprocess): + doc: | + Details about computational steps how the zero-loss peak was threaded. + (NXprogram): + doc: | + The program with which the zero-loss peak correction was performed. + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + (NXpeak): + doc: | + Name and location of each peak in the spectrum considered to be of relevance. + (NXspectrum): + doc: | + NXspectrum specialized for EELS. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e7654e681ca515cfec03ae8d5052c572a7f40c2770c5e0537e34df4897b2cfbd +# +# +# +# +# +# Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +# +# +# +# Details about computational steps how the zero-loss peak was threaded. +# +# +# +# The program with which the zero-loss peak correction was performed. +# +# +# +# +# +# Details about computational steps how peaks were indexed as elements. +# +# +# +# The program with which the indexing was performed. +# +# +# +# +# Name and location of each peak in the spectrum considered to be of relevance. +# +# +# +# +# NXspectrum specialized for EELS. +# +# +# +# diff --git a/base_classes/nyaml/NXem_img.yaml b/base_classes/nyaml/NXem_img.yaml new file mode 100644 index 0000000000..06668b77e4 --- /dev/null +++ b/base_classes/nyaml/NXem_img.yaml @@ -0,0 +1,98 @@ +category: base +doc: | + Base class for method-specific generic imaging with electron microscopes. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe regions-of-interest (ROIs). Examples can be single point aka spot + measurements, 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. +type: group +NXem_img(NXprocess): + (NXimage): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: + open_enum: true + items: [secondary_electron, backscattered_electron, annular_dark_field, cathodoluminescence] + half_angle_interval(NX_NUMBER): + unit: NX_ANGLE + doc: | + Annulus inner (first value) and outer (second value) half angle. + dimensions: + rank: 1 + dim: (2,) + + # already implemented connections to representations of microstructures but in this PR not proposed + # (NXmicrostructure): + # doc: | + # A reconstruction of the microstructure or some of its features + # based on image information in the parent class. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 399e311c8610e60a5a7e0d69f1271d29d19e6f12bb1cfe372c34eb72118daf3a +# +# +# +# +# +# Base class for method-specific generic imaging with electron microscopes. +# +# In the majority of cases simple d-dimensional regular scan patterns are used +# to probe regions-of-interest (ROIs). Examples can be single point aka spot +# measurements, 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. +# +# +# +# +# Which imaging mode was used? +# +# +# +# +# +# +# +# +# +# +# Annulus inner (first value) and outer (second value) half angle. +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXem_measurement.yaml b/base_classes/nyaml/NXem_measurement.yaml new file mode 100644 index 0000000000..48e4dc84a0 --- /dev/null +++ b/base_classes/nyaml/NXem_measurement.yaml @@ -0,0 +1,41 @@ +category: base +doc: | + Base class for documenting a measurement with an electron microscope. +type: group +NXem_measurement(NXobject): + instrument(NXinstrument_em): + eventID(NXevent_data_em): + nameType: partial + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b316172f1da3439b7e2e8914311c4473c77b211748924007325b78d22ab4bfa2 +# +# +# +# +# +# Base class for documenting a measurement with an electron microscope. +# +# +# +# diff --git a/base_classes/nyaml/NXem_simulation.yaml b/base_classes/nyaml/NXem_simulation.yaml new file mode 100644 index 0000000000..68eba8b949 --- /dev/null +++ b/base_classes/nyaml/NXem_simulation.yaml @@ -0,0 +1,44 @@ +category: base +doc: | + Base class for documenting a simulation of electron beam-matter interaction. +type: group +NXem_simulation(NXobject): + (NXprogram): + (NXparameters): + (NXprocess): + (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c481ee0c18dbbeebd612e013186b8f69866a0cdbc59610bd02a1d819a1af7af0 +# +# +# +# +# +# Base class for documenting a simulation of electron beam-matter interaction. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXevent_data_em.yaml b/base_classes/nyaml/NXevent_data_em.yaml new file mode 100644 index 0000000000..b423b02492 --- /dev/null +++ b/base_classes/nyaml/NXevent_data_em.yaml @@ -0,0 +1,286 @@ +category: base +doc: | + Base class to store state and (meta)data of events for electron microscopy. + + Event-related (meta)data, typically measured datasets like images and spectra. + To avoid repetitively storing static instrument-related metadata, + the dynamic (meta)data that typically changes for each image and spectrum + is split from the static (meta)data. + + Which temporal granularity is adequate to log events depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + + Electron microscopes are dynamic. Scientists often report that microscopes + *perform differently* across sessions. That *they* perform differently from + one day or another. In some cases, root causes for performance differences + are unclear. Users of the instrument may consider such conditions impractical, + or *too poor*, and thus abort their session. Alternatively, users may try to + bring the microscope into a state where conditions are considered better + or of whatever high enough quality for starting or continuing the measurement. + + In all these use cases it is useful to have a mechanism whereby time-dependent + data of the instrument state can be stored and documented in an representation + that facilitates interoperability. This is the idea behind this base class. + + :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly + whatever is considered a time interval during which the instrument is + considered stable enough for allowing any working on tasks with it. + Examples of such tasks are the collecting of data (images and spectra) or + the calibrating the instrument or individual of its components. Users may wish to take + only a single scan or image and complete their session thereafter. + Alternatively, users are working for much longer time at the instrument, + perform recalibrations in between and take several scans (of different + ROIs on the specimen), or they explore the state of the microscope for + service or maintenance tasks. + + :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: + + * Firstly, via a header section whose purpose is to contextualize + and identify the event instance in time. + * Secondly, via a data and metadata section where individual data + collections can be stored in a standardized representation. + + We are aware of the fact that given the variety how an electron microscope + is used, there is a need for a flexible and adaptive documentation system. + At the same time we are also convinced though that just because one has + different requirements for some specific aspect under the umbrella of settings + to an electron microscope, this does not necessarily warrant that one has to + cook up an own data schema. + + Instead, the electron microscopy community should work towards reusing schema + components as frequently as possible. This will enable that there is at all + not only a value of harmonizing electron microscopy research content but also + there is a technical possibility to build services around such harmonized data. + + 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 a stack of spectra. Having to deal with instabilities is a common theme in + electron microscopy practice. Numerical protocols can be used during data + post-processing to correct for some of the instabilities. + A few exemplar references provide an overview on the subject: + + * `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 (digital twin), 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 and ions, or detector noise models. + This also warrants to document the time-dependent details of individual components + of the microscope via the here implemented class :ref:`NXevent_data_em`. +type: group +NXevent_data_em(NXobject): + 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 users wish 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. + identifier_event(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of a specific state and setting of the microscope. + identifier_sample(NX_CHAR): + unit: NX_UNITLESS + doc: | + The name of the sample to resolve ambiguities. + type(NX_CHAR): + 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 for which there is at the moment no other place. + + In the long run such free-text field description should be avoided as + it is difficult to machine-interpret. Instead, an enumeration should + be used. + (NXuser): + (NXinstrument_em): + (NXimage): + (NXspectrum): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9ab7fcd4482d84b1a491b17d7985199287f979dd3f253d941dd6318c428e09db +# +# +# +# +# +# Base class to store state and (meta)data of events for electron microscopy. +# +# Event-related (meta)data, typically measured datasets like images and spectra. +# To avoid repetitively storing static instrument-related metadata, +# the dynamic (meta)data that typically changes for each image and spectrum +# is split from the static (meta)data. +# +# Which temporal granularity is adequate to log events depends on the situation and +# research question. Using a model which enables a collection of events offers +# the most flexible way to cater for both experiments with controlled electron +# beams in a real microscope or the simulation of such experiments or +# individual aspects of such experiments. +# +# Electron microscopes are dynamic. Scientists often report that microscopes +# *perform differently* across sessions. That *they* perform differently from +# one day or another. In some cases, root causes for performance differences +# are unclear. Users of the instrument may consider such conditions impractical, +# or *too poor*, and thus abort their session. Alternatively, users may try to +# bring the microscope into a state where conditions are considered better +# or of whatever high enough quality for starting or continuing the measurement. +# +# In all these use cases it is useful to have a mechanism whereby time-dependent +# data of the instrument state can be stored and documented in an representation +# that facilitates interoperability. This is the idea behind this base class. +# +# :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly +# whatever is considered a time interval during which the instrument is +# considered stable enough for allowing any working on tasks with it. +# Examples of such tasks are the collecting of data (images and spectra) or +# the calibrating the instrument or individual of its components. Users may wish to take +# only a single scan or image and complete their session thereafter. +# Alternatively, users are working for much longer time at the instrument, +# perform recalibrations in between and take several scans (of different +# ROIs on the specimen), or they explore the state of the microscope for +# service or maintenance tasks. +# +# :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: +# +# * Firstly, via a header section whose purpose is to contextualize +# and identify the event instance in time. +# * Secondly, via a data and metadata section where individual data +# collections can be stored in a standardized representation. +# +# We are aware of the fact that given the variety how an electron microscope +# is used, there is a need for a flexible and adaptive documentation system. +# At the same time we are also convinced though that just because one has +# different requirements for some specific aspect under the umbrella of settings +# to an electron microscope, this does not necessarily warrant that one has to +# cook up an own data schema. +# +# Instead, the electron microscopy community should work towards reusing schema +# components as frequently as possible. This will enable that there is at all +# not only a value of harmonizing electron microscopy research content but also +# there is a technical possibility to build services around such harmonized data. +# +# 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 a stack of spectra. Having to deal with instabilities is a common theme in +# electron microscopy practice. Numerical protocols can be used during data +# post-processing to correct for some of the instabilities. +# A few exemplar references provide an overview on the subject: +# +# * `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 (digital twin), 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 and ions, or detector noise models. +# This also warrants to document the time-dependent details of individual components +# of the microscope via the here implemented class :ref:`NXevent_data_em`. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval started. +# +# If users wish 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. +# +# +# +# +# Identifier of a specific state and setting of the microscope. +# +# +# +# +# The name of the sample to resolve ambiguities. +# +# +# +# +# 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 for which there is at the moment no other place. +# +# In the long run such free-text field description should be avoided as +# it is difficult to machine-interpret. Instead, an enumeration should +# be used. +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXibeam_column.yaml b/base_classes/nyaml/NXibeam_column.yaml new file mode 100644 index 0000000000..053539929e --- /dev/null +++ b/base_classes/nyaml/NXibeam_column.yaml @@ -0,0 +1,267 @@ +category: base +doc: | + Base class for a set of components equipping an instrument with FIB capabilities. + + Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped + with sufficient ion having sufficient momentum to remove material in a controlled + manner. + + The fact that an electron microscope with FIB capabilities achieves these functionalities + via a second component (aka the ion gun) that has its own relevant control circuits, + focusing lenses, and other components, warrants the definition of 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 `_ + * `N. Yao `_ +type: group +NXibeam_column(NXcomponent): + operation_mode(NX_CHAR): + doc: | + Tech-partner, microscope-, and control-software-specific name of the + specific operation mode how the ibeam_column and its components are + controlled to achieve specific illumination conditions. + + In many cases the users of an instrument do not or can not be expected to know + all intricate spatiotemporal dynamics of their hardware. Instead, they rely on + assumptions that the instrument, its control software, and components work as + expected to focus on their research questions. + + For these cases, having a place for documenting the operation_mode is useful + in as much as at least some constraints on how the illumination conditions were + is documented. + ion_source(NXsource): + doc: | + The source which creates the ion beam. + name(NX_CHAR): + doc: | + Given name/alias for the ion gun. + emitter_type(NX_CHAR): + 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(NX_CHAR): + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + probe(NXatom): + doc: | + Which elements, ions, or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + flux(NX_NUMBER): + unit: NX_ANY + doc: | + Average/nominal flux + brightness(NX_NUMBER): + unit: NX_ANY + doc: | + Average/nominal brightness + + # \@units: A/cm*sr + # NEW ISSUE: (at which location?). + current(NX_NUMBER): + unit: NX_CURRENT + doc: | + Charge current + voltage(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Ion acceleration voltage upon source exit and + entering the vacuum flight path. + ion_energy_profile(NX_NUMBER): + unit: NX_ENERGY + doc: | + To be defined more specifically. Community suggestions are welcome. + (NXlens_em): + (NXaperture): + (NXdeflector): + blankerID(NXdeflector): + nameType: partial + doc: | + A component for blanking the ion beam or generating pulsed ion beams. + (NXmonochromator): + (NXsensor): + (NXactuator): + (NXbeam): + doc: | + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + :ref:`NXtransformations` should be used to specify the location or position + at which details about the ion beam are probed. + (NXcomponent): + scan_controller(NXscanbox_em): + + # for further ideas and comments inspect version + # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e356277247fb026a2da1d36ca8c4c0dcf2bb29b6abe3e9e56e940721a7485f5a +# +# +# +# +# +# Base class for a set of components equipping an instrument with FIB capabilities. +# +# Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped +# with sufficient ion having sufficient momentum to remove material in a controlled +# manner. +# +# The fact that an electron microscope with FIB capabilities achieves these functionalities +# via a second component (aka the ion gun) that has its own relevant control circuits, +# focusing lenses, and other components, warrants the definition of 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>`_ +# * `N. Yao <https://doi.org/10.1017/CBO9780511600302>`_ +# +# +# +# Tech-partner, microscope-, and control-software-specific name of the +# specific operation mode how the ibeam_column and its components are +# controlled to achieve specific illumination conditions. +# +# In many cases the users of an instrument do not or can not be expected to know +# all intricate spatiotemporal dynamics of their hardware. Instead, they rely on +# assumptions that the instrument, its control software, and components work as +# expected to focus on their research questions. +# +# For these cases, having a place for documenting the operation_mode is useful +# in as much as at least some constraints on how the illumination conditions were +# is documented. +# +# +# +# +# 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 elements, ions, or molecular ions form the beam. +# Examples are gallium, helium, neon, argon, krypton, +# or xenon, O2+. +# +# +# +# +# Average/nominal flux +# +# +# +# +# Average/nominal brightness +# +# +# +# +# +# Charge current +# +# +# +# +# Ion acceleration voltage upon source exit and +# entering the vacuum flight path. +# +# +# +# +# To be defined more specifically. Community suggestions are welcome. +# +# +# +# +# +# +# +# +# A component for blanking the ion beam or generating pulsed ion beams. +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the ion beam. +# +# :ref:`NXtransformations` should be used to specify the location or position +# at which details about the ion beam are probed. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXimage.yaml b/base_classes/nyaml/NXimage.yaml index 3845faea1a..90c9028c7a 100644 --- a/base_classes/nyaml/NXimage.yaml +++ b/base_classes/nyaml/NXimage.yaml @@ -10,10 +10,9 @@ doc: | pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - image point is eventually more appropriate when working with such tilings. + (image) point is eventually more appropriate when working with such tilings. - Therefore, all docstrings in this base class refer to points. Points are considered - exact synonyms for pixel and voxel, which are terms used for regular tilings. + Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). Point coordinates identify the location of the barycenter. @@ -39,13 +38,26 @@ doc: | That is indices_image are always counting from offset in increments of one as each image is its own entity. By contrast, a group may contain no, or several images. Consequently, indices_group are not required to be contiguous. + + Classically, images depict objects in real space. Such usage of NXimage essentially is equivalent to + storing pictures. For this purpose the image_1d, image_2d, or image_3d NXdata instances respectively + should be used with all their axes axis_i, axis_j, axis_k constrained to NeXus Unit Category NX_LENGTH. + + Imaging modes in electron microscopy are typically more versatile, specifically for use cases + in scanning transmission electron microscopy, so-called 4DSTEM. In this case, one two-dimensional + diffraction image is taken for each point that gets scanned in real space. Consequently, + image_3d and image_4d NXdata instances should be used for these cases with axis_k and axis_m + respectively of NeXus Unit Category NX_LENGTH and axis_i and axis_j respectively of + NeXus Unit Category NX_WAVENUMBER. # set of frequently made specializations of NXdata instances for images symbols: n_img: | Number of images in the stack, for stacks the slowest dimension. + n_m: | + Number of image points along the slowest dimension. n_k: | - Number of image points along the slow dimension (k equivalent to z). + Number of image points along the slow dimension. n_j: | Number of image points along the fast dimension (j equivalent to y). n_i: | @@ -111,9 +123,14 @@ NXimage(NXobject): rank: 1 dim: (n_i,) axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -154,9 +171,14 @@ NXimage(NXobject): rank: 2 dim: (n_j, n_i) axis_j(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_j,) @@ -164,9 +186,14 @@ NXimage(NXobject): doc: | Point coordinate along the fast dimension. axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -207,9 +234,107 @@ NXimage(NXobject): rank: 3 dim: (n_k, n_j, n_i) axis_k(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY + doc: | + Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + dimensions: + rank: 1 + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension. + axis_j(NX_NUMBER): + unit: NX_ANY + doc: | + Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + dimensions: + rank: 1 + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension. + axis_i(NX_NUMBER): + unit: NX_ANY + doc: | + Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + dimensions: + rank: 1 + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fastest dimension. + image_4d(NXdata): + doc: | + Four-dimensional image. + intensity(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + dimensions: + rank: 4 + dim: (n_m, n_k, n_j, n_i) + real(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Real part of the image intensity per point. + dimensions: + rank: 4 + dim: (n_m, n_k, n_j, n_i) + imag(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Imaginary part of the image intensity per point. + dimensions: + rank: 4 + dim: (n_m, n_k, n_j, n_i) + complex(NX_COMPLEX): + unit: NX_UNITLESS + doc: | + Image intensity as a complex number as an alternative to real and + imag fields if values are stored as interleaved complex numbers. + dimensions: + rank: 4 + dim: (n_m, n_k, n_j, n_i) + axis_m(NX_NUMBER): + unit: NX_ANY + doc: | + Point coordinate along the slowest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. + dimensions: + rank: 1 + dim: (n_m,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slowest dimension. + axis_k(NX_NUMBER): + unit: NX_ANY doc: | Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_k,) @@ -217,9 +342,14 @@ NXimage(NXobject): doc: | Point coordinate along the slow dimension. axis_j(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_j,) @@ -227,9 +357,14 @@ NXimage(NXobject): doc: | Point coordinate along the fast dimension. axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -290,9 +425,14 @@ NXimage(NXobject): doc: | Image identifier axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -353,9 +493,14 @@ NXimage(NXobject): doc: | Image identifier. axis_j(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_j,) @@ -363,9 +508,14 @@ NXimage(NXobject): doc: | Point coordinate along the fast dimension. axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -426,9 +576,14 @@ NXimage(NXobject): doc: | Image identifier axis_k(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the slow dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_k,) @@ -436,9 +591,14 @@ NXimage(NXobject): doc: | Point coordinate along the slow dimension. axis_j(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fast dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_j,) @@ -446,9 +606,14 @@ NXimage(NXobject): doc: | Point coordinate along the fast dimension. axis_i(NX_NUMBER): - unit: NX_LENGTH + unit: NX_ANY doc: | Point coordinate along the fastest dimension. + + Different NeXus Unit Category are allowed: + + * NX_LENGTH for images slicing real space. + * NX_WAVENUMBER for images slicing reciprocal space. dimensions: rank: 1 dim: (n_i,) @@ -457,7 +622,7 @@ NXimage(NXobject): Point coordinate along the fastest dimension. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 53d9ce9754bf5da4922a7f90786b4ddbff14bbd5846e6bbb2836bdf0480ae2cf +# 43dd29e12e292bdbdc94021d51a153557efdcf3a308f9f900e3cbebcf4d5766e # # # +# +# +# Base class for instrument-related details of a real or simulated electron microscope. +# +# For collecting data and experiments which are simulations of an electron +# microscope (or such session) use the :ref:`NXem` application definition and +# the :ref:`NXevent_data_em` groups it provides. +# +# This base class implements the concept of :ref:`NXem` whereby (meta)data are distinguished +# whether these typically change during a session (dynamic) or not (static metadata). +# This design allows to store e.g. hardware related concepts only once instead of demanding +# that each image or spectrum from the session needs to be stored also with the static metadata. +# +# +# +# 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. +# +# +# +# +# Different types of electron microscopes exist: +# +# * sem, a scanning electron microscope without focused-ion beam capabilities +# * fib, a scanning electron microscope with focused-ion beam capabilities +# irrespective whether these were used or not +# * tem, a transmission electron microscope +# +# NXem is one joint data model that can be used to document research that is performed +# with several of these types of microscopes (SEM, TEM, or FIB). The NXem data model +# stresses that these types of instruments despite having several differences are still all +# electron beamlines with which to probe electron and/or ion matter interaction and in fact +# in practice have many similarities in how they are used, the components, they contain, etc. +# +# This field can be used in research data management systems for enabling a categorization +# or tagging of experiments without having to analyze if groups like NXibeam_column are present +# (which would indicate type is fib) or if certain lens configurations or instrument models are used +# which suggests the microscope is a scanning (sem) or transmission electron microscope (tem): +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# Stages in an electron microscope are multi-functional devices. +# +# Stages enable experimentalists the application of controlled external stimuli +# on the specimen. Modern stages realize a hierarchy of components. +# A multi-axial tilt rotation holder is a good example where the control of +# each degree of freedom is technically implemented via providing instances +# of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating +# and positioning of the specimen. +# +# The physical process of mounting a specimen on a stage in practice often +# comes with an own hierarchy of fixtures to bridge e.g. length scales technically. +# An example from atom probe microscopy is that researchers may work +# with wire samples which are clipped into a larger fixing unit to enable +# careful specimen handling. Alternatively, a microtip is a silicon post +# upon which e.g. an atom probe specimen is mounted. Multiple of such microtips +# are then grouped into a microtip array to conveniently enable loading of multiple +# specimens into the instrument with fewer operations. There are further scenarios +# typically encountered related to mounting and locating specimens inside an +# electron microscope, a few examples follow: +# +# * A nanoparticle on a copper grid. The copper grid is the holder. +# This grid itself is fixed to a stage. +# * An atom probe specimen fixed in a stub. In this case the stub can be +# considered the holder, while the cryostat temperature control unit is +# a component of the stage. +# * For in-situ experiments with e.g. chips with read-out electronics +# as actuators, the chips are again placed in a larger unit. A typical +# example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. +# * Other examples are (quasi) in-situ experiments where experimentalists +# anneal or deform the specimen via e.g. in-situ tensile testing machines +# which are mounted on the specimen holder. +# +# For specific details and inspiration about stages in electron microscopes: +# +# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ +# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ +# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ +# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) +# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) +# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) +# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ +# +# +# +# +# Principal design of the stage. +# +# Exemplar terms could be side_entry, top_entry, +# single_tilt, quick_change, multiple_specimen, +# bulk_specimen, double_tilt, tilt_rotate, +# heating_chip, atmosphere_chip, +# electrical_biasing_chip, liquid_cell_chip +# +# +# +# +# Free-text field to give a term how that a stage_lab at this level of the +# stage_lab hierarchy is commonly referred to. Examples could be stub, +# puck, carousel, microtip, clip, holder, etc. +# +# +# +# +# +# The interpretation of this tilt1 value can be contextualized via the comment +# attribute. However, it is better to describe the reference frame in which the +# tilt is defined explicitly using instances of :ref:`NXtransformations` and +# respective instances of :ref:`NXcoordinate_system`. Especially when this +# NXinstrument_em base class is used in an application definition like NXem. +# +# +# +# Discouraged free-text field to provide details about how to interpret tilt1. +# +# +# +# +# +# The interpretation of this tilt2 value can be contextualized via the comment +# attribute. However, it is better to describe the reference frame in which the +# tilt is defined explicitly using instances of :ref:`NXtransformations` and +# respective instances of :ref:`NXcoordinate_system`. Especially when this +# NXinstrument_em base class is used in an application definition like NXem. +# +# +# +# Discouraged free-text field to provide details about how to interpret tilt2. +# +# +# +# +# +# The interpretation of this rotation value can be contextualized via the comment +# attribute. However, it is better to describe the reference frame in which the +# rotation is defined explicitly using instances of :ref:`NXtransformations` and +# respective instances of :ref:`NXcoordinate_system`. Especially when this +# NXinstrument_em base class is used in an application definition like NXem. +# +# +# +# Discouraged free-text field to provide details about how to interpret rotation. +# +# +# +# +# +# The interpretation of these position values can be contextualized via the comment +# attribute. However, it is better to describe the reference frame in which the +# position values are defined explicitly using instances of :ref:`NXtransformations` +# and respective instances of :ref:`NXcoordinate_system`. Especially when this +# NXinstrument_em base class is used in an application definition like NXem. +# +# +# +# +# +# +# +# +# In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically +# frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and +# relocated portions of the specimen that have been cut off during site-specific lift-outs +# and specimen preparation. +# +# +# +# +# Gas injection systems (GIS) are components of microscopes that are equipped with focused-ion beam +# capabilities. The component is used to introduce reactive neutral gases to the sample surface for +# enhanced etching, preferential etching, or material deposition. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXinteraction_volume_em.yaml b/base_classes/nyaml/NXinteraction_volume_em.yaml new file mode 100644 index 0000000000..bfbd5805b4 --- /dev/null +++ b/base_classes/nyaml/NXinteraction_volume_em.yaml @@ -0,0 +1,92 @@ +category: base +doc: | + Base class to describe the volume of interaction for particle-matter interaction. + + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle-resolved sets of trajectories. + + Explicit or implicit descriptions of the geometry of this + interaction volume 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 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 flux through + an imaginary control surface (the iso-surface) 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. `_ + * `J. F. Ziegler et al. `_ +type: group +NXinteraction_volume_em(NXobject): + (NXdata): + (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# aaed5462265171d4bd795348fcd1907519dfa4b05b484b9457cdd10661855ace +# +# +# +# +# +# Base class to describe the volume of interaction for particle-matter interaction. +# +# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam +# interaction simulations can be used to qualify and (or) quantify the shape of +# the interaction volume. Results of such simulations can be summary statistics +# or single-particle-resolved sets of trajectories. +# +# Explicit or implicit descriptions of the geometry of this +# interaction volume 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 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 flux through +# an imaginary control surface (the iso-surface) 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>`_ +# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ +# +# +# +# diff --git a/base_classes/nyaml/NXoptical_system_em.yaml b/base_classes/nyaml/NXoptical_system_em.yaml new file mode 100644 index 0000000000..e5c6016bcb --- /dev/null +++ b/base_classes/nyaml/NXoptical_system_em.yaml @@ -0,0 +1,306 @@ +category: base +doc: | + Base class for qualifying an electron optical system. +type: group +NXoptical_system_em(NXobject): + camera_length(NX_NUMBER): + unit: NX_LENGTH + doc: + - | + Distance which is present between the specimen surface and the detector plane. + - | + xref: + spec: EMglossary + term: Camera Length + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 + magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The factor of enlargement of the apparent size, + not the physical size, of an object. + defocus(NX_NUMBER): + unit: NX_LENGTH + doc: | + The defocus aberration constant (oftentimes referred to as c_1_0). + See respective details in :ref:`NXaberration` class instances. + semi_convergence_angle(NX_NUMBER): + unit: NX_ANGLE + doc: + - | + The angle which is given by the semi-opening angle of the cone in a convergent + beam. + - | + xref: + spec: EMglossary + term: Convergence Angle + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 + field_of_view(NX_NUMBER): + unit: NX_LENGTH + doc: | + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + working_distance(NX_NUMBER): + unit: NX_LENGTH + doc: + - | + Distance which is determined along the optical axis within the column from (1) the + lower end of the final optical element between the source and the specimen stage; + to (2) the point where the beam is focused. + - | + xref: + spec: EMglossary + term: Working Distance + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 + + # use NXcg_ellipsoid in the future for probe + probe(NX_NUMBER): + doc: | + Geometry of the cross-section formed when the primary beam shines onto the + specimen surface. Reported as length of the semiaxes of the ellipsoidal + cross-section with semiaxes values sorted by decreasing length. + dimensions: + rank: 1 + dim: (2,) + + # dimensions: + # rank: 2 + probe_current(NX_NUMBER): + unit: NX_CURRENT + doc: + - | + Electrical current which arrives at the specimen. + - | + xref: + spec: EMglossary + term: Probe Current + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 + dose_management(NX_CHAR): + doc: | + Specify further details how incipient electron or ion dose was quantified + (using beam_current, probe_current). + + `Reference `_ discusses + an approach for (electron) dose monitoring in an electron microscope. + + The unit of the nominal dose rate is e-/(angstrom^2*s). + dose_rate(NX_NUMBER): + unit: 1/(angstrom^2*s) + doc: | + Nominal dose rate. + rotation(NX_NUMBER): + unit: NX_ANGLE + doc: | + In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated + on a helical path about the optical axis. This causes an image rotation whose strength + is affected by the magnification. + + Microscopes may be equipped with compensation methods (implemented in hardware + or software) that reduce but not necessarily eliminate this rotation. + + See `L. Reimer `_ for details. + focal_length(NX_NUMBER): + unit: NX_LENGTH + doc: + - | + Distance which lies between the principal plane of the lens and the focal point + along the optical axis. + - | + xref: + spec: EMglossary + term: Focal Length + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 + tilt_correction(NX_BOOLEAN): + doc: + - | + Details about an imaging setting used during acquisition to correct perspective + distortion when imaging a tilted surface or cross section. + - | + xref: + spec: EMglossary + term: Tilt Correction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 + dynamic_focus_correction(NX_BOOLEAN): + doc: + - | + Details about a dynamic focus correction used. + - | + xref: + spec: EMglossary + term: Dynamic Focus Correction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 + dynamic_refocusing(NX_CHAR): + doc: + - | + Details about a workflow used to keep the specimen in focus by automatic means. + - | + xref: + spec: EMglossary + term: Dynamic Refocusing + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3c4d0f8e7769e89e527b6ecf6119664bf46a23a0af0b503fe90fb1659a211ce6 +# +# +# +# +# +# Base class for qualifying an electron optical system. +# +# +# +# Distance which is present between the specimen surface and the detector plane. +# +# This concept is related to term `Camera Length`_ of the EMglossary standard. +# +# .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 +# +# +# +# +# The factor of enlargement of the apparent size, +# not the physical size, of an object. +# +# +# +# +# The defocus aberration constant (oftentimes referred to as c_1_0). +# See respective details in :ref:`NXaberration` class instances. +# +# +# +# +# The angle which is given by the semi-opening angle of the cone in a convergent +# beam. +# +# This concept is related to term `Convergence Angle`_ of the EMglossary standard. +# +# .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 +# +# +# +# +# The extent of the observable parts of the specimen given the current +# magnification and other settings of the instrument. +# +# +# +# +# Distance which is determined along the optical axis within the column from (1) the +# lower end of the final optical element between the source and the specimen stage; +# to (2) the point where the beam is focused. +# +# This concept is related to term `Working Distance`_ of the EMglossary standard. +# +# .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 +# +# +# +# +# +# Geometry of the cross-section formed when the primary beam shines onto the +# specimen surface. Reported as length of the semiaxes of the ellipsoidal +# cross-section with semiaxes values sorted by decreasing length. +# +# +# +# +# +# +# +# +# Electrical current which arrives at the specimen. +# +# This concept is related to term `Probe Current`_ of the EMglossary standard. +# +# .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 +# +# +# +# +# Specify further details how incipient electron or ion dose was quantified +# (using beam_current, probe_current). +# +# `Reference <https://doi.org/10.1017/S1551929522000840>`_ discusses +# an approach for (electron) dose monitoring in an electron microscope. +# +# The unit of the nominal dose rate is e-/(angstrom^2*s). +# +# +# +# +# Nominal dose rate. +# +# +# +# +# In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated +# on a helical path about the optical axis. This causes an image rotation whose strength +# is affected by the magnification. +# +# Microscopes may be equipped with compensation methods (implemented in hardware +# or software) that reduce but not necessarily eliminate this rotation. +# +# See `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ for details. +# +# +# +# +# Distance which lies between the principal plane of the lens and the focal point +# along the optical axis. +# +# This concept is related to term `Focal Length`_ of the EMglossary standard. +# +# .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 +# +# +# +# +# Details about an imaging setting used during acquisition to correct perspective +# distortion when imaging a tilted surface or cross section. +# +# This concept is related to term `Tilt Correction`_ of the EMglossary standard. +# +# .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 +# +# +# +# +# Details about a dynamic focus correction used. +# +# This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. +# +# .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 +# +# +# +# +# Details about a workflow used to keep the specimen in focus by automatic means. +# +# This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. +# +# .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 +# +# +# diff --git a/base_classes/nyaml/NXphase.yaml b/base_classes/nyaml/NXphase.yaml new file mode 100644 index 0000000000..265c1ff5f6 --- /dev/null +++ b/base_classes/nyaml/NXphase.yaml @@ -0,0 +1,98 @@ +category: base +doc: | + Base class to describe a (thermodynamic) phase as a component of a material. + + Instances of phases can be crystalline. +type: group +NXphase(NXobject): + phase_id(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model (no sufficiently significant information available). + In other words, the phase_name is n/a aka notIndexed. + + The identifier_phase value should match with the integer suffix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if three phases were used e.g. 0, 1, and 2, three instances of + :ref:`NXphase` named phase0, phase1, and phase2 should be stored + in that HDF5 file. + name(NX_CHAR): + doc: | + Given name as an alias for identifying this phase. + + If the identifier_phase is 0 and one would like to use + the field name, the value should be n/a or notIndexed. + (NXunit_cell): + (NXatom): + + # support for microstructures that are not proposed to the NIAC in this PR + # + # + # + # + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c3f6ab4b062c5931c08b935347f3644680f0174dc555816e987ca72d94045bb5 +# +# +# +# +# +# Base class to describe a (thermodynamic) phase as a component of a material. +# +# Instances of phases can be crystalline. +# +# +# +# Identifier for each phase. +# +# The value 0 is reserved for the unknown phase that represents the +# null-model (no sufficiently significant information available). +# In other words, the phase_name is n/a aka notIndexed. +# +# The identifier_phase value should match with the integer suffix of the +# group name which represents that instance in a NeXus/HDF5 file, i.e. +# if three phases were used e.g. 0, 1, and 2, three instances of +# :ref:`NXphase` named phase0, phase1, and phase2 should be stored +# in that HDF5 file. +# +# +# +# +# Given name as an alias for identifying this phase. +# +# If the identifier_phase is 0 and one would like to use +# the field name, the value should be n/a or notIndexed. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXrotations.yaml b/base_classes/nyaml/NXrotations.yaml new file mode 100644 index 0000000000..d9e2bbfbd8 --- /dev/null +++ b/base_classes/nyaml/NXrotations.yaml @@ -0,0 +1,439 @@ +category: base + +# can this class take the name from the deprecated NXorientation class? +doc: | + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge `_ + * `T. B. Britton et al. `_ + * `D. Rowenhorst et al. `_ + * `A. Morawiec `_ + + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet `_ + + The concepts of mis- and disorientation are relevant when analyzing the + crystallography of interfaces. +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 value tuples. + n_phases: | + How many phases with usually different crystal and symmetry are distinguished. +type: group +NXrotations(NXobject): + reference_frame(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` which contextualizes + how the here reported parameterized quantities can be interpreted. + crystal_symmetry(NX_CHAR): + doc: | + Point group which defines the symmetry of the crystal. + + This has to be at least a single string. If crystal_symmetry is not + provided, point group 1 is assumed. + + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field needs to encode two strings: + The first string is for phase A. The second string is for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + dimensions: + rank: 1 + dim: (n_phases,) + sample_symmetry(NX_CHAR): + doc: | + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided, point group 1 is assumed. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, have become obsolete thanks + to improvements in methods, software, and available computing power. + + Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed, and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description should be avoided. + dimensions: + rank: 1 + dim: (n_phases,) + rotation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. + dimensions: + rank: 2 + dim: (c, 4) + rotation_euler(NX_NUMBER): + unit: NX_ANGLE + doc: | + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many possible + Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dimensions: + rank: 2 + dim: (c, 3) + + # rotation_rodrigues(NX_NUMBER): + # rotation_homochoric(NX_NUMBER): + # rotation_axis_angle(NX_NUMBER): + + # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry + is_antipodal(NX_BOOLEAN): + doc: | + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + dimensions: + rank: 1 + dim: (c,) + orientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The set of orientations expressed in quaternion parameterization and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations with the antipodal property. + dimensions: + rank: 2 + dim: (c, 4) + orientation_euler(NX_NUMBER): + unit: NX_ANGLE + doc: | + The set of orientations expressed in Euler angle parameterization following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the rotation + conventions behind reference_frame to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dimensions: + rank: 2 + dim: (c, 3) + + # orientation_rodrigues(NX_NUMBER): + # orientation_homochoric(NX_NUMBER): + # orientation_axis_angle(NX_NUMBER): + misorientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The set of misorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + The misorientation should not be confused with the disorientation, + as for the latter the angular argument is expected to be the minimal + obeying symmetries. + dimensions: + rank: 2 + dim: (c, 4) + misorientation_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + dimensions: + rank: 1 + dim: (c,) + misorientation_axis(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + dimensions: + rank: 2 + dim: (c, 3) + + # disorientation, misorientation with smallest angular argument inside + # fundamental zone of SO3 for given crystal and sample symmetry + disorientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The set of disorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent disorientations + as defined by crystal_symmetry and sample_symmetry. + dimensions: + rank: 2 + dim: (c, 4) + disorientation_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Disorientations angular argument (should not be signed, see + `D. Rowenhorst et al. `_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + dimensions: + rank: 1 + dim: (c,) + disorientation_axis(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Disorientations axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_angle. + dimensions: + rank: 2 + dim: (c, 3) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 239aa437e4fe8b7fac66e7536590b07dbedff1e73a6f5361bff263fae970c716 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of value tuples. +# +# +# +# +# How many phases with usually different crystal and symmetry are distinguished. +# +# +# +# +# +# Base class to detail a set of rotations, orientations, and disorientations. +# +# For getting a more detailed insight into the discussion of the +# parameterized description of orientations in materials science see: +# +# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ +# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ +# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ +# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ +# +# Once orientations are defined, one can continue to characterize the +# misorientation and specifically the disorientation. The misorientation describes +# the rotation that is required to register the lattices of two oriented objects +# (like crystal lattice) into a crystallographic equivalent orientation: +# +# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ +# +# The concepts of mis- and disorientation are relevant when analyzing the +# crystallography of interfaces. +# +# +# +# Reference to an instance of :ref:`NXcoordinate_system` which contextualizes +# how the here reported parameterized quantities can be interpreted. +# +# +# +# +# Point group which defines the symmetry of the crystal. +# +# This has to be at least a single string. If crystal_symmetry is not +# provided, point group 1 is assumed. +# +# In the case that misorientation or disorientation fields are used +# and the two crystal sets resolve for phases with a different +# crystal symmetry, this field needs to encode two strings: +# The first string is for phase A. The second string is for phase B. +# An example of this most complex case is the description of the +# disorientation between crystals adjoining a hetero-phase boundary. +# +# +# +# +# +# +# +# Point group which defines an assumed symmetry imprinted upon processing +# the material/sample which could give rise to or may justify to use a +# simplified description of rotations, orientations, misorientations, +# and disorientations via numerical procedures that are known as +# symmetrization. +# +# If sample_symmetry is not provided, point group 1 is assumed. +# +# The traditionally used symmetrization operations within the texture +# community in Materials Science, though, have become obsolete thanks +# to improvements in methods, software, and available computing power. +# +# Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). +# +# In practice one often faces situations where indeed these assumed +# symmetries are anyway not fully observed, and thus an accepting of +# eventual inaccuracies just for the sake of reporting a simplified +# symmetrized description should be avoided. +# +# +# +# +# +# +# +# The set of rotations expressed in quaternion parameterization considering +# crystal_symmetry and sample_symmetry. Rotations which should be +# interpreted as antipodal are not marked as such. +# +# +# +# +# +# +# +# +# The set of rotations expressed in Euler angle parameterization considering +# the same applied symmetries as detailed for the field rotation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the rotation +# conventions behind reference_frame to resolve which of the many possible +# Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# +# +# True for all those value tuples which have assumed antipodal symmetry. +# False for all others. +# +# +# +# +# +# +# +# The set of orientations expressed in quaternion parameterization and +# obeying symmetry for equivalent cases as detailed in crystal_symmetry +# and sample_symmetry. The supplementary field is_antipodal can be used +# to mark orientations with the antipodal property. +# +# +# +# +# +# +# +# +# The set of orientations expressed in Euler angle parameterization following +# the same assumptions like for orientation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the rotation +# conventions behind reference_frame to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# +# The set of misorientations expressed in quaternion parameterization +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# The misorientation should not be confused with the disorientation, +# as for the latter the angular argument is expected to be the minimal +# obeying symmetries. +# +# +# +# +# +# +# +# +# Misorientation angular argument (eventually signed) following the same +# symmetry assumptions as expressed for the field misorientation_quaternion. +# +# +# +# +# +# +# +# Misorientation axis (normalized) and signed following the same +# symmetry assumptions as expressed for the field misorientation_angle. +# +# +# +# +# +# +# +# +# +# The set of disorientations expressed in quaternion parameterization +# obeying symmetry operations for equivalent disorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# +# +# +# +# +# +# +# Disorientations angular argument (should not be signed, see +# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) +# following the same symmetry assumptions as expressed for the field +# disorientation_quaternion. +# +# +# +# +# +# +# +# Disorientations axis (normalized) following the same symmetry assumptions +# as expressed for the field disorientation_angle. +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXscanbox_em.yaml b/base_classes/nyaml/NXscanbox_em.yaml new file mode 100644 index 0000000000..22bf6bdb2b --- /dev/null +++ b/base_classes/nyaml/NXscanbox_em.yaml @@ -0,0 +1,143 @@ +category: base +doc: | + The scan box or scan controller is a component that is used to deflect a + beam of charged particles in a controlled manner. + + The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, + which is not necessarily the same program as the one controlling other parts of the instrument. + + The scanbox directs the probe of charged particles (electrons, ions) + to controlled locations according to a scan scheme and plan. +type: group +NXscanbox_em(NXcomponent): + + # user perspective + scan_schema(NX_CHAR): + doc: | + Name of the typically tech-partner-specific term that specifies an + automated protocol which details how the components of the scan_box + and the instrument work together to achieve a controlled + scanning of the beam (over the sample surface). + + Oftentimes users do not need to or are not able to disentangle the intricate + details of the spatiotemporal dynamics of their instrument. Instead, often + they rely on the assumption that the instrument and its controlling programs + work as expected. The field scan_schema can be used to add some constraints + on how the beam was scanned over the surface. + + # descriptors relevant from economic usage (costs) of the instrument and dose management perspective (radiation damage) + dwell_time(NX_NUMBER): + unit: NX_TIME + doc: + - | + Time period during which the beam remains at one position. + - | + xref: + spec: EMglossary + term: Dwell Time + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 + flyback_time(NX_NUMBER): + unit: NX_TIME + doc: + - | + Time period during which the beam moves from the final position of one scan + line to the starting position of the subsequent scan line. + - | + xref: + spec: EMglossary + term: Flyback Time + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 + + # technical design perspective + (NXdeflector): + doc: | + Details about components which realize the deflection technically. + + This concept should be used for all those components that implement + the scanning of the beam, while components like beam blankers etc. should + use rather the NXdeflector concept of the NXebeam_column base class. + (NXcircuit): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8cf16f3012c5e68900c560231e39e80a92b03f9edd08868e79a957c5fd04d5fb +# +# +# +# +# +# The scan box or scan controller is a component that is used to deflect a +# beam of charged particles in a controlled manner. +# +# The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, +# which is not necessarily the same program as the one controlling other parts of the instrument. +# +# The scanbox directs the probe of charged particles (electrons, ions) +# to controlled locations according to a scan scheme and plan. +# +# +# +# +# Name of the typically tech-partner-specific term that specifies an +# automated protocol which details how the components of the scan_box +# and the instrument work together to achieve a controlled +# scanning of the beam (over the sample surface). +# +# Oftentimes users do not need to or are not able to disentangle the intricate +# details of the spatiotemporal dynamics of their instrument. Instead, often +# they rely on the assumption that the instrument and its controlling programs +# work as expected. The field scan_schema can be used to add some constraints +# on how the beam was scanned over the surface. +# +# +# +# +# +# Time period during which the beam remains at one position. +# +# This concept is related to term `Dwell Time`_ of the EMglossary standard. +# +# .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 +# +# +# +# +# Time period during which the beam moves from the final position of one scan +# line to the starting position of the subsequent scan line. +# +# This concept is related to term `Flyback Time`_ of the EMglossary standard. +# +# .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 +# +# +# +# +# +# Details about components which realize the deflection technically. +# +# This concept should be used for all those components that implement +# the scanning of the beam, while components like beam blankers etc. should +# use rather the NXdeflector concept of the NXebeam_column base class. +# +# +# +# From ccac1385260a6cfe530d0b2088aa1504cb660a69 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 15 Jul 2025 14:39:11 +0200 Subject: [PATCH 39/57] Brought back (speculatively) cg classes FAIRmat and pre-FAIRmat ones, also updated all XML headers from discouraged single to double straight quotes, all nyamls reprocessed clean --- base_classes/NXcalibration.nxdl.xml | 2 +- base_classes/NXcg_alpha_complex.nxdl.xml | 101 ++++ base_classes/NXcg_cylinder.nxdl.xml | 133 ++++++ base_classes/NXcg_ellipsoid.nxdl.xml | 81 ++++ .../NXcg_face_list_data_structure.nxdl.xml | 227 +++++++++ base_classes/NXcg_grid.nxdl.xml | 177 +++++++ .../NXcg_half_edge_data_structure.nxdl.xml | 195 ++++++++ base_classes/NXcg_hexahedron.nxdl.xml | 191 ++++++++ base_classes/NXcg_parallelogram.nxdl.xml | 101 ++++ base_classes/NXcg_point.nxdl.xml | 87 ++++ base_classes/NXcg_polygon.nxdl.xml | 126 +++++ base_classes/NXcg_polyhedron.nxdl.xml | 104 +++++ base_classes/NXcg_polyline.nxdl.xml | 140 ++++++ base_classes/NXcg_primitive.nxdl.xml | 247 ++++++++++ base_classes/NXcg_roi.nxdl.xml | 49 ++ base_classes/NXcg_tetrahedron.nxdl.xml | 76 +++ base_classes/NXcg_triangle.nxdl.xml | 92 ++++ base_classes/NXcg_unit_normal.nxdl.xml | 75 +++ base_classes/nyaml/NXcalibration.yaml | 2 +- base_classes/nyaml/NXcg_alpha_complex.yaml | 166 +++++++ base_classes/nyaml/NXcg_cylinder.yaml | 229 ++++++++++ base_classes/nyaml/NXcg_ellipsoid.yaml | 131 ++++++ .../nyaml/NXcg_face_list_data_structure.yaml | 397 ++++++++++++++++ base_classes/nyaml/NXcg_grid.yaml | 307 +++++++++++++ .../nyaml/NXcg_half_edge_data_structure.yaml | 341 ++++++++++++++ base_classes/nyaml/NXcg_hexahedron.yaml | 342 ++++++++++++++ base_classes/nyaml/NXcg_parallelogram.yaml | 172 +++++++ base_classes/nyaml/NXcg_point.yaml | 139 ++++++ base_classes/nyaml/NXcg_polygon.yaml | 217 +++++++++ base_classes/nyaml/NXcg_polyhedron.yaml | 170 +++++++ base_classes/nyaml/NXcg_polyline.yaml | 238 ++++++++++ base_classes/nyaml/NXcg_primitive.yaml | 432 ++++++++++++++++++ base_classes/nyaml/NXcg_roi.yaml | 77 ++++ base_classes/nyaml/NXcg_tetrahedron.yaml | 120 +++++ base_classes/nyaml/NXcg_triangle.yaml | 145 ++++++ base_classes/nyaml/NXcg_unit_normal.yaml | 120 +++++ contributed_definitions/NXaberration.nxdl.xml | 2 +- contributed_definitions/NXafm.nxdl.xml | 2 +- contributed_definitions/NXamplifier.nxdl.xml | 2 +- contributed_definitions/NXapm.nxdl.xml | 2 +- .../NXapm_charge_state_analysis.nxdl.xml | 2 +- .../NXapm_compositionspace_config.nxdl.xml | 2 +- .../NXapm_compositionspace_results.nxdl.xml | 2 +- .../NXapm_measurement.nxdl.xml | 2 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 2 +- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 2 +- .../NXapm_paraprobe_distancer_config.nxdl.xml | 2 +- ...NXapm_paraprobe_distancer_results.nxdl.xml | 2 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 2 +- ...apm_paraprobe_intersector_results.nxdl.xml | 2 +- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 2 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 2 +- .../NXapm_paraprobe_ranger_config.nxdl.xml | 2 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_config.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 2 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 2 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 2 +- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 2 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 2 +- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 2 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 2 +- .../NXapm_paraprobe_tool_common.nxdl.xml | 2 +- .../NXapm_paraprobe_tool_config.nxdl.xml | 2 +- .../NXapm_paraprobe_tool_results.nxdl.xml | 2 +- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 2 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 2 +- .../NXapm_ranging.nxdl.xml | 2 +- .../NXapm_reconstruction.nxdl.xml | 2 +- .../NXapm_simulation.nxdl.xml | 2 +- contributed_definitions/NXatom.nxdl.xml | 2 +- .../NXbeam_splitter.nxdl.xml | 2 +- .../NXbias_spectroscopy.nxdl.xml | 2 +- .../NXcantilever_spm.nxdl.xml | 2 +- .../NXcg_alpha_complex.nxdl.xml | 2 +- .../NXcg_cylinder.nxdl.xml | 2 +- .../NXcg_ellipsoid.nxdl.xml | 2 +- contributed_definitions/NXcg_grid.nxdl.xml | 2 +- contributed_definitions/NXcg_point.nxdl.xml | 2 +- .../NXcg_unit_normal.nxdl.xml | 2 +- .../NXchemical_composition.nxdl.xml | 2 +- contributed_definitions/NXcircuit.nxdl.xml | 2 +- .../NXcorrector_cs.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 2 +- contributed_definitions/NXcs_memory.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 2 +- contributed_definitions/NXcs_process.nxdl.xml | 2 +- .../NXcs_profiling.nxdl.xml | 2 +- .../NXcs_profiling_event.nxdl.xml | 2 +- contributed_definitions/NXcs_storage.nxdl.xml | 2 +- .../NXdelocalization.nxdl.xml | 2 +- .../NXdispersion_function.nxdl.xml | 2 +- .../NXdispersion_repeated_parameter.nxdl.xml | 2 +- .../NXdispersive_material.nxdl.xml | 2 +- .../NXebeam_column.nxdl.xml | 2 +- .../NXelectrostatic_kicker.nxdl.xml | 2 +- contributed_definitions/NXem.nxdl.xml | 2 +- .../NXem_calorimetry.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- .../NXem_measurement.nxdl.xml | 2 +- .../NXem_simulation.nxdl.xml | 2 +- .../NXevent_data_apm.nxdl.xml | 2 +- .../NXevent_data_em.nxdl.xml | 2 +- .../NXibeam_column.nxdl.xml | 2 +- contributed_definitions/NXimage.nxdl.xml | 2 +- .../NXinstrument_apm.nxdl.xml | 2 +- .../NXinstrument_em.nxdl.xml | 2 +- .../NXinteraction_volume_em.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 2 +- contributed_definitions/NXisocontour.nxdl.xml | 2 +- ...ctro_chemo_mechanical_preparation.nxdl.xml | 2 +- .../NXlab_sample_mounting.nxdl.xml | 2 +- contributed_definitions/NXlockin.nxdl.xml | 2 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXmicrostructure.nxdl.xml | 2 +- .../NXmicrostructure_feature.nxdl.xml | 2 +- .../NXmicrostructure_gragles_config.nxdl.xml | 2 +- .../NXmicrostructure_gragles_results.nxdl.xml | 2 +- .../NXmicrostructure_imm_config.nxdl.xml | 2 +- .../NXmicrostructure_imm_results.nxdl.xml | 2 +- .../NXmicrostructure_ipf.nxdl.xml | 2 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 2 +- .../NXmicrostructure_mtex_config.nxdl.xml | 2 +- .../NXmicrostructure_odf.nxdl.xml | 2 +- .../NXmicrostructure_pf.nxdl.xml | 2 +- .../NXmicrostructure_score_config.nxdl.xml | 2 +- .../NXmicrostructure_score_results.nxdl.xml | 2 +- .../NXmicrostructure_slip_system.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 2 +- contributed_definitions/NXphase.nxdl.xml | 2 +- .../NXpiezo_config_spm.nxdl.xml | 2 +- .../NXpiezoelectric_material.nxdl.xml | 2 +- .../NXpolarizer_opt.nxdl.xml | 2 +- .../NXpositioner_spm.nxdl.xml | 2 +- contributed_definitions/NXpump.nxdl.xml | 2 +- contributed_definitions/NXrcs.nxdl.xml | 2 +- contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXrotations.nxdl.xml | 2 +- .../NXscan_control.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 2 +- .../NXsensor_scan.nxdl.xml | 2 +- .../NXsimilarity_grouping.nxdl.xml | 2 +- .../NXspatial_filter.nxdl.xml | 2 +- contributed_definitions/NXspectrum.nxdl.xml | 2 +- contributed_definitions/NXspm.nxdl.xml | 2 +- contributed_definitions/NXstm.nxdl.xml | 2 +- contributed_definitions/NXsts.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- contributed_definitions/NXsubstance.nxdl.xml | 2 +- .../NXtransmission.nxdl.xml | 2 +- contributed_definitions/NXunit_cell.nxdl.xml | 2 +- contributed_definitions/NXxrd.nxdl.xml | 2 +- contributed_definitions/NXxrd_pan.nxdl.xml | 2 +- .../nyaml/NXaberration.yaml | 2 +- contributed_definitions/nyaml/NXafm.yaml | 2 +- .../nyaml/NXamplifier.yaml | 2 +- contributed_definitions/nyaml/NXapm.yaml | 2 +- .../nyaml/NXapm_charge_state_analysis.yaml | 2 +- .../nyaml/NXapm_compositionspace_config.yaml | 2 +- .../nyaml/NXapm_compositionspace_results.yaml | 2 +- .../nyaml/NXapm_measurement.yaml | 2 +- .../NXapm_paraprobe_clusterer_config.yaml | 2 +- .../NXapm_paraprobe_clusterer_results.yaml | 2 +- .../NXapm_paraprobe_distancer_config.yaml | 2 +- .../NXapm_paraprobe_distancer_results.yaml | 2 +- .../NXapm_paraprobe_intersector_config.yaml | 2 +- .../NXapm_paraprobe_intersector_results.yaml | 2 +- .../NXapm_paraprobe_nanochem_config.yaml | 2 +- .../NXapm_paraprobe_nanochem_results.yaml | 2 +- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 2 +- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 2 +- .../NXapm_paraprobe_selector_config.yaml | 2 +- .../NXapm_paraprobe_selector_results.yaml | 2 +- .../NXapm_paraprobe_spatstat_config.yaml | 2 +- .../NXapm_paraprobe_spatstat_results.yaml | 2 +- .../NXapm_paraprobe_surfacer_config.yaml | 2 +- .../NXapm_paraprobe_surfacer_results.yaml | 2 +- .../NXapm_paraprobe_tessellator_config.yaml | 2 +- .../NXapm_paraprobe_tessellator_results.yaml | 2 +- .../nyaml/NXapm_paraprobe_tool_common.yaml | 2 +- .../nyaml/NXapm_paraprobe_tool_config.yaml | 2 +- .../nyaml/NXapm_paraprobe_tool_results.yaml | 2 +- .../NXapm_paraprobe_transcoder_config.yaml | 2 +- .../NXapm_paraprobe_transcoder_results.yaml | 2 +- .../nyaml/NXapm_ranging.yaml | 2 +- .../nyaml/NXapm_reconstruction.yaml | 2 +- .../nyaml/NXapm_simulation.yaml | 2 +- contributed_definitions/nyaml/NXatom.yaml | 2 +- .../nyaml/NXbeam_splitter.yaml | 2 +- .../nyaml/NXbias_spectroscopy.yaml | 2 +- .../nyaml/NXcantilever_spm.yaml | 2 +- .../nyaml/NXcg_alpha_complex.yaml | 2 +- .../nyaml/NXcg_cylinder.yaml | 2 +- .../nyaml/NXcg_ellipsoid.yaml | 2 +- contributed_definitions/nyaml/NXcg_grid.yaml | 2 +- contributed_definitions/nyaml/NXcg_point.yaml | 2 +- .../nyaml/NXcg_unit_normal.yaml | 2 +- .../nyaml/NXchemical_composition.yaml | 2 +- contributed_definitions/nyaml/NXcircuit.yaml | 2 +- .../nyaml/NXcorrector_cs.yaml | 2 +- .../nyaml/NXcs_computer.yaml | 2 +- .../nyaml/NXcs_filter_boolean_mask.yaml | 2 +- .../nyaml/NXcs_memory.yaml | 2 +- contributed_definitions/nyaml/NXcs_prng.yaml | 2 +- .../nyaml/NXcs_process.yaml | 2 +- .../nyaml/NXcs_profiling.yaml | 2 +- .../nyaml/NXcs_profiling_event.yaml | 2 +- .../nyaml/NXcs_storage.yaml | 2 +- .../nyaml/NXdelocalization.yaml | 2 +- .../nyaml/NXdispersion_function.yaml | 2 +- .../NXdispersion_repeated_parameter.yaml | 2 +- .../nyaml/NXdispersive_material.yaml | 2 +- .../nyaml/NXebeam_column.yaml | 2 +- .../nyaml/NXelectrostatic_kicker.yaml | 2 +- contributed_definitions/nyaml/NXem.yaml | 2 +- .../nyaml/NXem_calorimetry.yaml | 2 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 2 +- contributed_definitions/nyaml/NXem_eds.yaml | 2 +- contributed_definitions/nyaml/NXem_eels.yaml | 2 +- contributed_definitions/nyaml/NXem_img.yaml | 2 +- .../nyaml/NXem_measurement.yaml | 2 +- .../nyaml/NXem_simulation.yaml | 2 +- .../nyaml/NXevent_data_apm.yaml | 2 +- .../nyaml/NXevent_data_em.yaml | 2 +- .../nyaml/NXibeam_column.yaml | 2 +- contributed_definitions/nyaml/NXimage.yaml | 2 +- .../nyaml/NXinstrument_apm.yaml | 2 +- .../nyaml/NXinstrument_em.yaml | 2 +- .../nyaml/NXinteraction_volume_em.yaml | 2 +- contributed_definitions/nyaml/NXion.yaml | 2 +- .../nyaml/NXisocontour.yaml | 2 +- ..._electro_chemo_mechanical_preparation.yaml | 2 +- .../nyaml/NXlab_sample_mounting.yaml | 2 +- contributed_definitions/nyaml/NXlockin.yaml | 2 +- .../nyaml/NXmatch_filter.yaml | 2 +- .../nyaml/NXmicrostructure.yaml | 2 +- .../nyaml/NXmicrostructure_feature.yaml | 2 +- .../NXmicrostructure_gragles_config.yaml | 2 +- .../NXmicrostructure_gragles_results.yaml | 2 +- .../nyaml/NXmicrostructure_imm_config.yaml | 2 +- .../nyaml/NXmicrostructure_imm_results.yaml | 2 +- .../nyaml/NXmicrostructure_ipf.yaml | 2 +- .../NXmicrostructure_kanapy_results.yaml | 2 +- .../nyaml/NXmicrostructure_mtex_config.yaml | 2 +- .../nyaml/NXmicrostructure_odf.yaml | 2 +- .../nyaml/NXmicrostructure_pf.yaml | 2 +- .../nyaml/NXmicrostructure_score_config.yaml | 2 +- .../nyaml/NXmicrostructure_score_results.yaml | 2 +- .../nyaml/NXmicrostructure_slip_system.yaml | 2 +- .../nyaml/NXoptical_system_em.yaml | 2 +- contributed_definitions/nyaml/NXphase.yaml | 2 +- .../nyaml/NXpiezo_config_spm.yaml | 2 +- .../nyaml/NXpiezoelectric_material.yaml | 2 +- .../nyaml/NXpolarizer_opt.yaml | 2 +- .../nyaml/NXpositioner_spm.yaml | 2 +- contributed_definitions/nyaml/NXpump.yaml | 2 +- contributed_definitions/nyaml/NXrcs.yaml | 2 +- contributed_definitions/nyaml/NXroi.yaml | 2 +- .../nyaml/NXrotations.yaml | 2 +- .../nyaml/NXscan_control.yaml | 2 +- .../nyaml/NXscanbox_em.yaml | 2 +- .../nyaml/NXsensor_scan.yaml | 2 +- .../nyaml/NXsimilarity_grouping.yaml | 2 +- .../nyaml/NXspatial_filter.yaml | 2 +- contributed_definitions/nyaml/NXspectrum.yaml | 2 +- contributed_definitions/nyaml/NXspm.yaml | 2 +- contributed_definitions/nyaml/NXstm.yaml | 2 +- contributed_definitions/nyaml/NXsts.yaml | 2 +- .../nyaml/NXsubsampling_filter.yaml | 2 +- .../nyaml/NXsubstance.yaml | 2 +- .../nyaml/NXtransmission.yaml | 2 +- .../nyaml/NXunit_cell.yaml | 2 +- contributed_definitions/nyaml/NXxrd.yaml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 2 +- 278 files changed, 6189 insertions(+), 244 deletions(-) create mode 100644 base_classes/NXcg_alpha_complex.nxdl.xml create mode 100644 base_classes/NXcg_cylinder.nxdl.xml create mode 100644 base_classes/NXcg_ellipsoid.nxdl.xml create mode 100644 base_classes/NXcg_face_list_data_structure.nxdl.xml create mode 100644 base_classes/NXcg_grid.nxdl.xml create mode 100644 base_classes/NXcg_half_edge_data_structure.nxdl.xml create mode 100644 base_classes/NXcg_hexahedron.nxdl.xml create mode 100644 base_classes/NXcg_parallelogram.nxdl.xml create mode 100644 base_classes/NXcg_point.nxdl.xml create mode 100644 base_classes/NXcg_polygon.nxdl.xml create mode 100644 base_classes/NXcg_polyhedron.nxdl.xml create mode 100644 base_classes/NXcg_polyline.nxdl.xml create mode 100644 base_classes/NXcg_primitive.nxdl.xml create mode 100644 base_classes/NXcg_roi.nxdl.xml create mode 100644 base_classes/NXcg_tetrahedron.nxdl.xml create mode 100644 base_classes/NXcg_triangle.nxdl.xml create mode 100644 base_classes/NXcg_unit_normal.nxdl.xml create mode 100644 base_classes/nyaml/NXcg_alpha_complex.yaml create mode 100644 base_classes/nyaml/NXcg_cylinder.yaml create mode 100644 base_classes/nyaml/NXcg_ellipsoid.yaml create mode 100644 base_classes/nyaml/NXcg_face_list_data_structure.yaml create mode 100644 base_classes/nyaml/NXcg_grid.yaml create mode 100644 base_classes/nyaml/NXcg_half_edge_data_structure.yaml create mode 100644 base_classes/nyaml/NXcg_hexahedron.yaml create mode 100644 base_classes/nyaml/NXcg_parallelogram.yaml create mode 100644 base_classes/nyaml/NXcg_point.yaml create mode 100644 base_classes/nyaml/NXcg_polygon.yaml create mode 100644 base_classes/nyaml/NXcg_polyhedron.yaml create mode 100644 base_classes/nyaml/NXcg_polyline.yaml create mode 100644 base_classes/nyaml/NXcg_primitive.yaml create mode 100644 base_classes/nyaml/NXcg_roi.yaml create mode 100644 base_classes/nyaml/NXcg_tetrahedron.yaml create mode 100644 base_classes/nyaml/NXcg_triangle.yaml create mode 100644 base_classes/nyaml/NXcg_unit_normal.yaml diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml index a0714fb323..2e7bee9891 100644 --- a/base_classes/NXcalibration.nxdl.xml +++ b/base_classes/NXcalibration.nxdl.xml @@ -1,4 +1,4 @@ - + + + + + Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about 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 of alpha shapes, and + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings + + in CGAL, the Computational Geometry Algorithms Library respectively. + As a starting point, we follow the conventions of the CGAL library. + + In general, an alpha complex is a not necessarily connected or not necessarily pure complex, + i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific + alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and + regularization can be used to provide details about regularization procedures. + + + + Type of alpha complex following the terminology used by CGAL for now. + + Alpha_shape means meshes created using one of the alpha_shape algorithm. + Alpha_wrapping means meshes created using the alpha_wrapping algorithm. + + + + + + + + + + Human-readable description about regularization procedures. + + + + + Was the alpha complex regularized, i.e. have singular faces been removed, or not. + + + + + The alpha parameter, i.e. the squared radius of the alpha-sphere + that is used when computing the alpha complex. + + + + + The offset distance parameter used when computing alpha_wrappings. + + + + + + Point cloud serving as input for the computation of the alpha complex. + + + + + Triangle soup serving as input for the computation of the alpha complex. + + + + + Triangle mesh representing the output of the computation, i.e. the alpha complex. + + + + + Tetrahedra representing an interior volume of the alpha complex (if such exists). + + + diff --git a/base_classes/NXcg_cylinder.nxdl.xml b/base_classes/NXcg_cylinder.nxdl.xml new file mode 100644 index 0000000000..2459121170 --- /dev/null +++ b/base_classes/NXcg_cylinder.nxdl.xml @@ -0,0 +1,133 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the space in which the members are assumed embedded. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of cylinders or (truncated) cones. + + The radius can either be defined in the radii field or by filling the upper_cap_radii + and lower_cap_radii fields respectively. The latter field case can + thus be used to represent (truncated) cones. + + It is possible to define only one of the cap_radii fields + to represent half-open cylinder. + + + + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. + + The upper_cap is assumed to represent the end while the + lower_cap is assumed to represent the start of the + respective cylinder instances when inspecting along the + direction vector. + + + + + + + + + Radius of the cylinder if all have the same radius. + + + + + Radii of the cylinder. + + + + + + + + Radii of the upper circular cap. + + This field, combined with lower_cap_radius can be used to describe + (eventually truncated) circular cones. + + + + + + + + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. + + + + + + + + + Lateral surface area of each cylinder. + + + + + + + + Area of the upper cap of each cylinder. + + + + + + + + Area of the lower cap of each cylinder. + + + + + + + + Sum of upper and lower cap area and lateral surface area of each cylinder. + + + + + + diff --git a/base_classes/NXcg_ellipsoid.nxdl.xml b/base_classes/NXcg_ellipsoid.nxdl.xml new file mode 100644 index 0000000000..c34a4897e7 --- /dev/null +++ b/base_classes/NXcg_ellipsoid.nxdl.xml @@ -0,0 +1,81 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the space in which the members are assumed embedded. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of ellipsoids. + + + + Length of the semi-axes (e.g. semi-major and semi-minor + respectively for an ellipse). + + Use if all ellipsoids in the set have the same half-axes. + + + + + + + + Length of the semi-axes if ellipsoids have individually different lengths. + + + + + + + + + + In the case that all ellipsoids are spheres. + + + + + In the case that all ellipsoids are spheres whose radii differ. + For a mixture of spheres use semi_axes_values. + + + + + + + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 0000000000..5fcfde6822 --- /dev/null +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,227 @@ + + + + + + + + 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. + + + + + Computational geometry of primitives via a face-and-edge-list data structure. + + Primitives must neither be degenerated nor self-intersect but can have different + properties. A face-and-edge-list-based description of primitives is + frequently used for triangles and polyhedra to store them on disk for + visualization purposes (see OFF, PLY, VTK, or STL file formats). + + Although this description is storage efficient, it is not well-suited for + topological analyses. In this case using a half-edge data structure is + an alternative. + + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or detailed specification demands. + + Indices can be used as identifier and thus names for individual instances. + + + + + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + + + + + + + + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + + + + + + Number of faces of the primitives. + + + + + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer identifier to distinguish all vertices explicitly. + + + + + + + + Integer used to distinguish all edges explicitly. + + + + + + + + Integer used to distinguish all faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in more efficient storage. Alternatively, storing vertex positions naively + should be indicated with setting vertices_are_unique to False. + Naively means that each vertex is stored even though many vertices may + share the same positions. + + + + + + + + + The edges are stored as pairs of vertex identifier. + + + + + + + + + The faces are stored as a concatenated array of vertex identifier tuples. + + 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: :math:`[\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 more + than once. + + + + + If true, indicates that no edge is stored more than once. + + Users are encouraged to consider using a half_edge_data_structure instead. + + + + + If true, indicates that no face is stored more than once. + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml new file mode 100644 index 0000000000..07abb1001a --- /dev/null +++ b/base_classes/NXcg_grid.nxdl.xml @@ -0,0 +1,177 @@ + + + + + + + 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 aka grid points. + + + + + Number of boundaries of the bounding box or primitive housing the grid. + + + + + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. + + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Numerical methods and models that use grids are used + in many cases in the natural sciences and engineering disciplines. Examples are + discretizations in space and time used for phase-field, cellular automata, or Monte Carlo + modeling. + + + + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive` + class to specify the coordinate system in which the origin location is defined. + + + + + + + + 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. + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + Coordinate of each cell with respect to the discrete grid. + + + + + + + + + + A tight bounding box about the grid. + + + + + + Number of boundaries distinguished + + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of domain boundaries of the simulation box/ROI + 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 + + + + + + + + Details about the computational geometry method and implementation + used for discretizing internal surfaces as e.g. obtained with marching methods, + like marching squares or marching cubes. + + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. + 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 ideally be an identifier of a program. + If not possible, an identifier for a paper, technical report, or free-text + description can be used instead. + + + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml new file mode 100644 index 0000000000..91eb74bc44 --- /dev/null +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -0,0 +1,195 @@ + + + + + + + + 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 geometry 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. The data structure is also + known as a doubly connected edge list. + + Indices can be used as identifier and thus names for individual instances. + + + + Dimensionality of the primitives described. + + + + + + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + + + + + + + + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + + + + + + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + + 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/base_classes/NXcg_hexahedron.nxdl.xml b/base_classes/NXcg_hexahedron.nxdl.xml new file mode 100644 index 0000000000..2684550116 --- /dev/null +++ b/base_classes/NXcg_hexahedron.nxdl.xml @@ -0,0 +1,191 @@ + + + + + + + + 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. + + 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 an approach whereby + different specific views can be implemented using the same base class: + + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of hexahedra is offered to serve additional 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. + + As a specialization of the :ref:`NXcg_primitive` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making 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 + tightly fitting box about an arbitrary object. In general, such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist to compute optimal or near optimal bounding boxes for sets of points. + + + + + Qualifier for the shape of each hexahedron. + + + + + + + + + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. + + + + + + + + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. + + + + + + + + Volume of each hexahedron. + + + + + + + + Total (surface) 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 coordinate system. + + + + + + + + + + + + Combined storage of all primitives of all hexahedra. + + + + + Individual storage of each hexahedron. + + + + + Individual storage of each hexahedron as a graph. + + + diff --git a/base_classes/NXcg_parallelogram.nxdl.xml b/base_classes/NXcg_parallelogram.nxdl.xml new file mode 100644 index 0000000000..f54790ce5f --- /dev/null +++ b/base_classes/NXcg_parallelogram.nxdl.xml @@ -0,0 +1,101 @@ + + + + + + + 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. + + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: + + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. + + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. + + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing 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, i.e. + most tightly 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 an optimal bounding box to a point set in 2D. + + + + + To specify which parallelogram is a rectangle. + + + + + + + + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. + + + + + + + + + Combined storage of all parallelograms. + + + + + Individual storage of each parallelogram. + + + diff --git a/base_classes/NXcg_point.nxdl.xml b/base_classes/NXcg_point.nxdl.xml new file mode 100644 index 0000000000..169abbe893 --- /dev/null +++ b/base_classes/NXcg_point.nxdl.xml @@ -0,0 +1,87 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points. + + Points may have an associated time value. Users are advised though to store + time data of point sets rather as instances of time events, where for each + point in time there is an :ref:`NXcg_point` 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 (real time or + simulated physical time). Thereby, the storage of redundant timestamp + information per point is considered as obsolete. + + + + Coordinates of the points. + + + + + + + + + (Elapsed) time for each point. + + If the field time is needed contextualize the time_offset relative to which + time values are defined. Alternative store timestamp. + + + + + + + + ISO8601 with local time zone offset for each point. + + + + + + + + ISO8601 with local time zone offset that serves as the reference + for values in the field time. + + + diff --git a/base_classes/NXcg_polygon.nxdl.xml b/base_classes/NXcg_polygon.nxdl.xml new file mode 100644 index 0000000000..d20f4aed81 --- /dev/null +++ b/base_classes/NXcg_polygon.nxdl.xml @@ -0,0 +1,126 @@ + + + + + + + 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design their own base class + e.g. NXcg_polytope to describe such even more complex primitives instead + of abusing this base class for such purposes. + + + + The total number of vertices in the set. + + + + + + Combined storage of all primitives of all polygons. + + + + + Individual storage of the mesh of each polygon. + + + + + Individual storage of each polygon as a graph. + + + + + + For each polygon its accumulated length along its edges. + + + + + + + + Interior angles for each polygon. There are as many values per polygon + as there are 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 + + + + + + diff --git a/base_classes/NXcg_polyhedron.nxdl.xml b/base_classes/NXcg_polyhedron.nxdl.xml new file mode 100644 index 0000000000..5e72d6070f --- /dev/null +++ b/base_classes/NXcg_polyhedron.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + + 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 set of polyhedra in Euclidean space. + + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. + + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon`. + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. + + + + + + + + Area of each of faces. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counted for each polyhedron. + + + + + Length of each edge. + + + + + + + + + Combined storage of all primitives of all polyhedra. + + + + + Individual storage of each polyhedron. + + + + + Individual storage of each polygon as a graph. + + + diff --git a/base_classes/NXcg_polyline.nxdl.xml b/base_classes/NXcg_polyline.nxdl.xml new file mode 100644 index 0000000000..f5e247c756 --- /dev/null +++ b/base_classes/NXcg_polyline.nxdl.xml @@ -0,0 +1,140 @@ + + + + + + + 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. + + 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 traversal along the polyline when + walking from the first to the last vertex. + + + + Reference to an instance of :ref:`NXcg_point` which defines the + location of the vertices that are referred to in this + NXcg_polyline instance. + + + + + The total number of vertices that have different positions. + + + + + The total number of vertices, irrespective of their eventual uniqueness. + + + + + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. + + + + + + + + + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique positions and vertices + as this often supports with storing geometry data more efficiently. + 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 stores each vertex of a triangle mesh + even though many vertices are shared between triangles and thus + storing multiple copies of their positions is redundant. + + + + + + + + + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted several times. + + + + + Sequence of identifier for vertices how they build each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet at a vertex (assume for example that the second vertex + is shared and marking the junction between the two polylines), it is possible + that there are only five unique positions. This suggests to store five + unique vertices. + + A non-trivial example is a set with several polylines. Assume that each + has a different number of vertices. The array stores the identifier of + the vertices in the sequence how the polylines are visited: + + The first entry is the identifier of the first vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the first polyline. + Thereafter, the first vertex of the second polyline, and so on and so forth. + Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), + the vertices of the N-th polyline can be accessed on the array + index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. + + + + + + diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml new file mode 100644 index 0000000000..2f096e316d --- /dev/null +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the embedding space. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of primitives in Euclidean space. + + Primitives must neither be degenerated nor self-intersect. + Individual primitives can differ in their properties (e.g. size, shape, rotation). + + + + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. + + + + + The dimensionality of the primitive set with value up to d. + + + + + + + + + + + The cardinality of the primitive set. Value should be equal to c. + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Indices can be used as identifiers and thus names of instances. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + index_offset and cardinality. For example if identifier run from + -2 to 3 the value for index_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where index_offset is 1 and 0 respectively. + + + + + Identifier of each member for explicit indexing. + + + + + + + + The center of each primitive + + + + + + + + + True if the center is a center of mass. + + + + + + + + Shape of each primitive + + + + + + + + + Length of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + Width of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + Height of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + True if primitive is closed such that it has properties like area or volume. + + + + + + + + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + Volume is an N-D concept for values of dimensionality larger than 1, + Area is an alias for the two-dimensional case. + + + + + + + + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + + + + + + + + Direction unit vector which points along the + longest principal axis of each primitive. + + Use the depends_on attribute to specify in which coordinate system + these direction unit vectors are defined. + + + + + + + + + Do the primitives define a mesh. + + + + + Do the primitives define a triangle mesh or not. + + + + + Do the primitives discretize the surface of an object or not. + + + + + Do the primitives define a geodesic mesh or not. + + A geodesic surface mesh is a triangulated surface mesh with metadata which + can be used as an approximation to describe the surface of a sphere. + Triangulation of spheres are commonly used in Materials Science + for quantifying texture of materials, i.e. the relative rotation of + crystals to sample directions. + + For additional details or an introduction into the topic of geodesic meshes + see (from which specifically the section on subdivision schemes is relevant). + + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + + Earth scientists 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 software. For now we propose to use this + base class as a container for organizing data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + e.g. a geodesic (surface) mesh was instantiated as there are many + possibilities to do so. + + + + + Possibility to store details such as when primitives form a (specific) type + of mesh such as geodesic meshes. + + + + + + diff --git a/base_classes/NXcg_roi.nxdl.xml b/base_classes/NXcg_roi.nxdl.xml new file mode 100644 index 0000000000..329c767c4a --- /dev/null +++ b/base_classes/NXcg_roi.nxdl.xml @@ -0,0 +1,49 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to + define explicitly the reference frame in which the primitives are + defined. + + + + Base class for a region-of-interest (ROI) bound by geometric primitives. + + So-called region-of-interest(s) (ROIs) are typically used to describe a + region in space (and time) where an observation is made or for which + a computer simulation is performed with given boundary conditions. + + + + + + + + diff --git a/base_classes/NXcg_tetrahedron.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml new file mode 100644 index 0000000000..95bf4e02dc --- /dev/null +++ b/base_classes/NXcg_tetrahedron.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + + 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. + + Among hexahedral elements, tetrahedral elements are one of the most + frequently used geometric primitive for meshing and describing volumetric + objects in continuum-field simulations. + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Combined storage of all primitives of all tetrahedra. + + + + + Individual storage of each tetrahedron. + + + + + Individual storage of each tetrahedron as a graph. + + + diff --git a/base_classes/NXcg_triangle.nxdl.xml b/base_classes/NXcg_triangle.nxdl.xml new file mode 100644 index 0000000000..d6c91451b9 --- /dev/null +++ b/base_classes/NXcg_triangle.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + + 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. + + + + Number of unique vertices in the triangle set. + + + + + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. + + + + + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. + + + + + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. + + + + + + + + + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. + + + + + + + diff --git a/base_classes/NXcg_unit_normal.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml new file mode 100644 index 0000000000..5eaacd9e75 --- /dev/null +++ b/base_classes/NXcg_unit_normal.nxdl.xml @@ -0,0 +1,75 @@ + + + + + + + + + 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. + + Store normal vector information as properties of primitives. + Use only only as a child of an instance of :ref:`NXcg_primitive` + so that this instance acts as the parent to define a context. + + + + Direction of each normal - a unit normal. + + + + + + + + + An indicator which details the orientation of each normal vector + in relation to its primitive, assuming the object is viewed + from a position outside the object. + + * 0 - undefined + * 1 - outer unit normal vector + * 2 - inner unit normal vector + + + + + + diff --git a/base_classes/nyaml/NXcalibration.yaml b/base_classes/nyaml/NXcalibration.yaml index 76a4ad6476..e4975512b9 100644 --- a/base_classes/nyaml/NXcalibration.yaml +++ b/base_classes/nyaml/NXcalibration.yaml @@ -145,7 +145,7 @@ NXcalibration(NXprocess): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # f5654f5bdbdb2bd6e822f6157450547dba893407062dec07456dcbbf707b59ab -# +# # # +# +# +# +# Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about 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 of alpha shapes, and +# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings +# +# in CGAL, the Computational Geometry Algorithms Library respectively. +# As a starting point, we follow the conventions of the CGAL library. +# +# In general, an alpha complex is a not necessarily connected or not necessarily pure complex, +# i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific +# alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and +# regularization can be used to provide details about regularization procedures. +# +# +# +# Type of alpha complex following the terminology used by CGAL for now. +# +# Alpha_shape means meshes created using one of the alpha_shape algorithm. +# Alpha_wrapping means meshes created using the alpha_wrapping algorithm. +# +# +# +# +# +# +# +# +# +# Human-readable description about regularization procedures. +# +# +# +# +# Was the alpha complex regularized, i.e. have singular faces been removed, or not. +# +# +# +# +# The alpha parameter, i.e. the squared radius of the alpha-sphere +# that is used when computing the alpha complex. +# +# +# +# +# The offset distance parameter used when computing alpha_wrappings. +# +# +# +# +# +# Point cloud serving as input for the computation of the alpha complex. +# +# +# +# +# Triangle soup serving as input for the computation of the alpha complex. +# +# +# +# +# Triangle mesh representing the output of the computation, i.e. the alpha complex. +# +# +# +# +# Tetrahedra representing an interior volume of the alpha complex (if such exists). +# +# +# diff --git a/base_classes/nyaml/NXcg_cylinder.yaml b/base_classes/nyaml/NXcg_cylinder.yaml new file mode 100644 index 0000000000..d4241d7263 --- /dev/null +++ b/base_classes/nyaml/NXcg_cylinder.yaml @@ -0,0 +1,229 @@ +category: base +doc: | + Computational geometry description of a set of cylinders or (truncated) cones. + + The radius can either be defined in the radii field or by filling the upper_cap_radii + and lower_cap_radii fields respectively. The latter field case can + thus be used to represent (truncated) cones. + + It is possible to define only one of the cap_radii fields + to represent half-open cylinder. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space in which the members are assumed embedded. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_cylinder(NXcg_primitive): + height(NX_NUMBER): + unit: NX_LENGTH + doc: | + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. + + The upper_cap is assumed to represent the end while the + lower_cap is assumed to represent the start of the + respective cylinder instances when inspecting along the + direction vector. + dimensions: + rank: 2 + dim: (c, d) + radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + Radius of the cylinder if all have the same radius. + radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + Radii of the cylinder. + dimensions: + rank: 1 + dim: (c,) + upper_cap_radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + Radii of the upper circular cap. + + This field, combined with lower_cap_radius can be used to describe + (eventually truncated) circular cones. + dimensions: + rank: 1 + dim: (c,) + lower_cap_radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. + dimensions: + rank: 1 + dim: (c,) + + # properties of the cylinder + lateral_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Lateral surface area of each cylinder. + dimensions: + rank: 1 + dim: (c,) + upper_cap_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of the upper cap of each cylinder. + dimensions: + rank: 1 + dim: (c,) + lower_cap_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of the lower cap of each cylinder. + dimensions: + rank: 1 + dim: (c,) + total_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Sum of upper and lower cap area and lateral surface area of each cylinder. + dimensions: + rank: 1 + dim: (c,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 76c5b4bd257f27b6a670bec467a805643b68451a1ce96c9ecabd18c1499ee413 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the space in which the members are assumed embedded. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of cylinders or (truncated) cones. +# +# The radius can either be defined in the radii field or by filling the upper_cap_radii +# and lower_cap_radii fields respectively. The latter field case can +# thus be used to represent (truncated) cones. +# +# It is possible to define only one of the cap_radii fields +# to represent half-open cylinder. +# +# +# +# A direction vector which is parallel to the cylinder/cone axis +# and whose magnitude is the height of the cylinder/cone. +# +# The upper_cap is assumed to represent the end while the +# lower_cap is assumed to represent the start of the +# respective cylinder instances when inspecting along the +# direction vector. +# +# +# +# +# +# +# +# +# Radius of the cylinder if all have the same radius. +# +# +# +# +# Radii of the cylinder. +# +# +# +# +# +# +# +# Radii of the upper circular cap. +# +# This field, combined with lower_cap_radius can be used to describe +# (eventually truncated) circular cones. +# +# +# +# +# +# +# +# Radii of the upper circular cap. +# +# This field, combined with upper_cap_radius can be used to describe +# (eventually truncated) circular cones. +# +# +# +# +# +# +# +# +# Lateral surface area of each cylinder. +# +# +# +# +# +# +# +# Area of the upper cap of each cylinder. +# +# +# +# +# +# +# +# Area of the lower cap of each cylinder. +# +# +# +# +# +# +# +# Sum of upper and lower cap area and lateral surface area of each cylinder. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_ellipsoid.yaml b/base_classes/nyaml/NXcg_ellipsoid.yaml new file mode 100644 index 0000000000..de4540a021 --- /dev/null +++ b/base_classes/nyaml/NXcg_ellipsoid.yaml @@ -0,0 +1,131 @@ +category: base +doc: | + Computational geometry description of a set of ellipsoids. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space in which the members are assumed embedded. + c: | + The cardinality of the set, i.e. the number of members. + +# redundant as there is NXcsg, and NXquadric but easier to understand +type: group +NXcg_ellipsoid(NXcg_primitive): + semi_axes_value(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of the semi-axes (e.g. semi-major and semi-minor + respectively for an ellipse). + + Use if all ellipsoids in the set have the same half-axes. + dimensions: + rank: 1 + dim: (d,) + semi_axes_values(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of the semi-axes if ellipsoids have individually different lengths. + dimensions: + rank: 2 + dim: (c, d) + + # convenience dictionary entries when all ellipsoids in the set are spheres. + radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + In the case that all ellipsoids are spheres. + radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + In the case that all ellipsoids are spheres whose radii differ. + For a mixture of spheres use semi_axes_values. + dimensions: + rank: 1 + dim: (c,) + + # properties of ellipsoids + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eff8af12e9566880c60a744fdb0bd00203c6f04da4bdaffedc16def5d6a3bb29 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the space in which the members are assumed embedded. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of ellipsoids. +# +# +# +# Length of the semi-axes (e.g. semi-major and semi-minor +# respectively for an ellipse). +# +# Use if all ellipsoids in the set have the same half-axes. +# +# +# +# +# +# +# +# Length of the semi-axes if ellipsoids have individually different lengths. +# +# +# +# +# +# +# +# +# +# In the case that all ellipsoids are spheres. +# +# +# +# +# In the case that all ellipsoids are spheres whose radii differ. +# For a mixture of spheres use semi_axes_values. +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_face_list_data_structure.yaml b/base_classes/nyaml/NXcg_face_list_data_structure.yaml new file mode 100644 index 0000000000..078efbb0e1 --- /dev/null +++ b/base_classes/nyaml/NXcg_face_list_data_structure.yaml @@ -0,0 +1,397 @@ +category: base +doc: | + Computational geometry of primitives via a face-and-edge-list data structure. + + Primitives must neither be degenerated nor self-intersect but can have different + properties. A face-and-edge-list-based description of primitives is + frequently used for triangles and polyhedra to store them on disk for + visualization purposes (see OFF, PLY, VTK, or STL file formats). + + Although this description is storage efficient, it is not well-suited for + topological analyses. In this case using a half-edge data structure is + an alternative. + + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or detailed specification demands. + + Indices can be used as identifier and thus names for individual instances. +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. + +# duplicate of an NXoff_geometry ? +type: group +NXcg_face_list_data_structure(NXcg_primitive): + + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + dimensions: + rank: 1 + dim: (n_f,) + number_of_edges(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + dimensions: + rank: 1 + dim: (n_e,) + number_of_faces(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of faces of the primitives. + index_offset_vertex(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + index_offset_edge(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + index_offset_face(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + indices_vertex(NX_INT): + unit: NX_UNITLESS + doc: | + Integer identifier to distinguish all vertices explicitly. + dimensions: + rank: 1 + dim: (n_v,) + indices_edge(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish all edges explicitly. + dimensions: + rank: 1 + dim: (n_e,) + indices_face(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish all faces explicitly. + dimensions: + rank: 1 + dim: (n_f,) + vertices(NX_NUMBER): + unit: NX_ANY + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in more efficient storage. Alternatively, storing vertex positions naively + should be indicated with setting vertices_are_unique to False. + Naively means that each vertex is stored even though many vertices may + share the same positions. + dimensions: + rank: 2 + dim: (n_v, d) + edges(NX_INT): + unit: NX_UNITLESS + doc: | + The edges are stored as pairs of vertex identifier. + dimensions: + rank: 2 + dim: (n_e, 2) + faces(NX_INT): + unit: NX_UNITLESS + doc: | + The faces are stored as a concatenated array of vertex identifier tuples. + + 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + dimensions: + rank: 1 + dim: (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 more + than once. + edges_are_unique(NX_BOOLEAN): + doc: | + If true, indicates that no edge is stored more than once. + + Users are encouraged to consider using a half_edge_data_structure instead. + faces_are_unique(NX_BOOLEAN): + doc: | + If true, indicates that no face is stored more than once. + winding_order(NX_INT): + unit: NX_UNITLESS + doc: | + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + dimensions: + rank: 1 + dim: (n_f,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0c3df1a1a9726e2c06714aa526c35a2f5ac3da333275277f7ab65f85e663b105 +# +# +# +# +# +# +# +# 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. +# +# +# +# +# Computational geometry of primitives via a face-and-edge-list data structure. +# +# Primitives must neither be degenerated nor self-intersect but can have different +# properties. A face-and-edge-list-based description of primitives is +# frequently used for triangles and polyhedra to store them on disk for +# visualization purposes (see OFF, PLY, VTK, or STL file formats). +# +# Although this description is storage efficient, it is not well-suited for +# topological analyses. In this case using a half-edge data structure is +# an alternative. +# +# Having an own base class for the data structure how primitives are stored is +# useful to embrace both users with small or detailed specification demands. +# +# Indices can be used as identifier and thus names for individual instances. +# +# +# +# +# Number of vertices for each face. +# +# Each entry represents the total number of vertices for that face, +# irrespectively whether vertices are shared among faces or not. +# +# +# +# +# +# +# +# Number of edges for each face. +# +# Each entry represents the total number of edges for that face, +# irrespectively whether edges are shared across faces or not. +# +# +# +# +# +# +# +# Number of faces of the primitives. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the vertices differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the edges differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the faces differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive for further details. +# +# +# +# +# Integer identifier to distinguish all vertices explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish all edges explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish all faces explicitly. +# +# +# +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to a unique set as this may +# result in more efficient storage. Alternatively, storing vertex positions naively +# should be indicated with setting vertices_are_unique to False. +# Naively means that each vertex is stored even though many vertices may +# share the same positions. +# +# +# +# +# +# +# +# +# The edges are stored as pairs of vertex identifier. +# +# +# +# +# +# +# +# +# The faces are stored as a concatenated array of vertex identifier tuples. +# +# 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: :math:`[\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 more +# than once. +# +# +# +# +# If true, indicates that no edge is stored more than once. +# +# Users are encouraged to consider using a half_edge_data_structure instead. +# +# +# +# +# If true, indicates that no face is stored more than once. +# +# +# +# +# Specifies for each face which winding order was used if any: +# +# * 0 - undefined +# * 1 - counter-clockwise (CCW) +# * 2 - clock-wise (CW) +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_grid.yaml b/base_classes/nyaml/NXcg_grid.yaml new file mode 100644 index 0000000000..9a971cae8e --- /dev/null +++ b/base_classes/nyaml/NXcg_grid.yaml @@ -0,0 +1,307 @@ +category: base +doc: | + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. + + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Numerical methods and models that use grids are used + in many cases in the natural sciences and engineering disciplines. Examples are + discretizations in space and time used for phase-field, cellular automata, or Monte Carlo + modeling. +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 aka grid points. + n_b: | + Number of boundaries of the bounding box or primitive housing the grid. +type: group +NXcg_grid(NXcg_primitive): + origin(NX_NUMBER): + unit: NX_ANY + doc: | + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive` + class to specify the coordinate system in which the origin location is defined. + dimensions: + rank: 1 + dim: (d,) + symmetry(NX_CHAR): + doc: | + The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + unit: NX_LENGTH + doc: | + The unit cell dimensions using crystallographic notation. + dimensions: + rank: 1 + dim: (d,) + extent(NX_INT): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: (d,) + + # number_of_cells(NX_UINT): maybe already too trivial quantities + # should constraints on the grid be place here or not + position(NX_NUMBER): + unit: NX_ANY + doc: | + Position of each cell in Euclidean space. + dimensions: + rank: 2 + dim: (c, d) + coordinate(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + Coordinate of each cell with respect to the discrete grid. + dimensions: + rank: 2 + dim: (c, d) + + # this should be a ROI + bounding_box(NXcg_polyhedron): + doc: | + A tight bounding box about the grid. + + # does it have to be a tight bounding box? + # 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_UINT): + unit: NX_UNITLESS + doc: | + Number of boundaries distinguished + + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + boundaries(NX_CHAR): + doc: | + Name of domain boundaries of the simulation box/ROI + e.g. left, right, front, back, bottom, top. + dimensions: + rank: 1 + dim: (n_b,) + boundary_conditions(NX_INT): + unit: NX_UNITLESS + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + dimensions: + rank: 1 + dim: (n_b,) + surface_reconstruction(NX_CHAR): + doc: | + Details about the computational geometry method and implementation + used for discretizing internal surfaces as e.g. obtained with marching methods, + like marching squares or marching cubes. + + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. + 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 ideally be an identifier of a program. + If not possible, an identifier for a paper, technical report, or free-text + description can be used instead. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c5bee596e67c2209b40728d8aef705108736ff7e8edce3781bd661d458bfbe13 +# +# +# +# +# +# +# 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 aka grid points. +# +# +# +# +# Number of boundaries of the bounding box or primitive housing the grid. +# +# +# +# +# Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. +# +# Three-dimensional grids with cubic cells are if not the most frequently used +# example of such grids. Numerical methods and models that use grids are used +# in many cases in the natural sciences and engineering disciplines. Examples are +# discretizations in space and time used for phase-field, cellular automata, or Monte Carlo +# modeling. +# +# +# +# Location of the origin of the grid. +# +# Use the depends_on field that is inherited from the :ref:`NXcg_primitive` +# class to specify the coordinate system in which the origin location is defined. +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# Coordinate of each cell with respect to the discrete grid. +# +# +# +# +# +# +# +# +# +# A tight bounding box about the grid. +# +# +# +# +# +# Number of boundaries distinguished +# +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# Name of domain boundaries of the simulation box/ROI +# 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 +# +# +# +# +# +# +# +# Details about the computational geometry method and implementation +# used for discretizing internal surfaces as e.g. obtained with marching methods, +# like marching squares or marching cubes. +# +# Documenting which specific version was used helps with understanding how +# robust the results are with respect to the topology of the triangulation. +# 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 ideally be an identifier of a program. +# If not possible, an identifier for a paper, technical report, or free-text +# description can be used instead. +# +# +# diff --git a/base_classes/nyaml/NXcg_half_edge_data_structure.yaml b/base_classes/nyaml/NXcg_half_edge_data_structure.yaml new file mode 100644 index 0000000000..db5d3a300f --- /dev/null +++ b/base_classes/nyaml/NXcg_half_edge_data_structure.yaml @@ -0,0 +1,341 @@ +category: base +doc: | + Computational geometry 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. The data structure is also + known as a doubly connected edge list. + + Indices can be used as identifier and thus names for individual instances. + +# 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. +type: group +NXcg_half_edge_data_structure(NXcg_primitive): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + doc: | + Dimensionality of the primitives described. + + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + dimensions: + rank: 1 + dim: (n_f,) + number_of_edges(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + dimensions: + rank: 1 + dim: (n_he,) + index_offset_vertex(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + index_offset_edge(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + index_offset_face(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + # therefore, indices_ -vertex, -face, -half_edge are implicit + position(NX_NUMBER): + unit: NX_ANY + doc: | + The position of the vertices. + dimensions: + rank: 2 + dim: (n_v, d) + vertex_incident_half_edge(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of the incident half-edge. + dimensions: + rank: 1 + dim: (n_v,) + face_half_edge(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of the (starting)/associated half-edge of the face. + dimensions: + rank: 1 + dim: (n_f,) + half_edge_vertex_origin(NX_INT): + unit: NX_UNITLESS + doc: | + The identifier of the vertex from which this half-edge is outwards pointing. + dimensions: + rank: 1 + dim: (n_he,) + half_edge_twin(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of the associated oppositely pointing half-edge. + dimensions: + rank: 1 + dim: (n_he,) + half_edge_incident_face(NX_INT): + unit: NX_UNITLESS + doc: | + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + dimensions: + rank: 1 + dim: (n_he,) + half_edge_next(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of the next half-edge. + dimensions: + rank: 1 + dim: (n_he,) + half_edge_prev(NX_INT): + unit: NX_UNITLESS + doc: | + Identifier of the previous half-edge. + dimensions: + rank: 1 + dim: (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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b10ac48eea45ef41a87c498cb5948f0214ae0b644dac489dba9373b8f3afcff6 +# +# +# +# +# +# +# +# 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 geometry 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. The data structure is also +# known as a doubly connected edge list. +# +# Indices can be used as identifier and thus names for individual instances. +# +# +# +# Dimensionality of the primitives described. +# +# +# +# +# +# Number of vertices for each face. +# +# Each entry represents the total number of vertices for that face, +# irrespectively whether vertices are shared among faces or not. +# +# +# +# +# +# +# +# Number of edges for each face. +# +# Each entry represents the total number of edges for that face, +# irrespectively whether edges are shared across faces or not. +# +# +# +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the vertices differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive` for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the edges differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive` for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the faces differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive` for further details. +# +# +# +# +# +# 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/base_classes/nyaml/NXcg_hexahedron.yaml b/base_classes/nyaml/NXcg_hexahedron.yaml new file mode 100644 index 0000000000..f2af5f16d8 --- /dev/null +++ b/base_classes/nyaml/NXcg_hexahedron.yaml @@ -0,0 +1,342 @@ +category: base +doc: | + Computational geometry description of a set of hexahedra in Euclidean space. + + 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 an approach whereby + different specific views can be implemented using the same base class: + + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of hexahedra is offered to serve additional 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. + + As a specialization of the :ref:`NXcg_primitive` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making 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 + tightly fitting box about an arbitrary object. In general, such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist to compute optimal or near optimal bounding boxes for sets of points. +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. + +# 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 simplices 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 +type: group +NXcg_hexahedron(NXcg_primitive): + + # qualifiers and properties of hexahedra + shape(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier for the shape of each hexahedron. + dimensions: + rank: 2 + dim: (c, 3) + length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. + dimensions: + rank: 1 + dim: (c,) + width(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. + dimensions: + rank: 1 + dim: (c,) + height(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. + dimensions: + rank: 1 + dim: (c,) + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Volume of each hexahedron. + dimensions: + rank: 1 + dim: (c,) + area(NX_NUMBER): + unit: NX_AREA + doc: | + Total (surface) area (of all six faces) of each hexahedron. + dimensions: + rank: 1 + dim: (c,) + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of the six faces of each hexahedron. + dimensions: + rank: 2 + dim: (c, 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: (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 coordinate system. + dimensions: + rank: 1 + dim: (c,) + vertex_normal(NXcg_unit_normal): + edge_normal(NXcg_unit_normal): + face_normal(NXcg_unit_normal): + + # detailed mesh-based representation + hexahedra(NXcg_face_list_data_structure): + doc: | + Combined storage of all primitives of all hexahedra. + hexahedronID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of each hexahedron. + hexahedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial + doc: | + Individual storage of each hexahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9a91e731a011f357acdd1310cdece4aa43a4ec09ec35774d98505a570d5e986d +# +# +# +# +# +# +# +# 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. +# +# 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 an approach whereby +# different specific views can be implemented using the same base class: +# +# * In the simplest case experimentalists may use this base class to describe +# the dimensions or size of a specimen. In this case the alignment with axes +# is not relevant as eventually only the volume of the specimen is of interest. +# * In many cases, take for example an experiment where a specimen was cut out +# from a specifically deformed piece of material, the orientation of the +# specimen's edges with the experiment coordinate system is of high relevance. +# Examples include knowledge about the specimen edge, whether it is +# parallel to the rolling, the transverse, or the normal direction. +# * While the above-mentioned use cases are sufficient to pinpoint the sample +# within a known laboratory/experiment coordinate system, these descriptions +# are not detailed enough to specify e.g. a CAD model of the specimen. +# * Therefore, groups and fields for an additional, computational-geometry- +# based view of hexahedra is offered to serve additional 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. +# +# As a specialization of the :ref:`NXcg_primitive` base class hexahedra +# are assumed non-degenerated, closed, and built of polygons that are +# not self-intersecting. +# +# The term hexahedra will be used throughout this base class but includes +# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), +# and optimal bounding box (OBB). +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a cuboid whose edges are aligned with the +# base vectors of a coordinate system. As a part of binary trees, these data +# objects are important for making 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 +# tightly fitting box about an arbitrary object. In general, such boxes are +# rotated. Exact and substantially faster in practice approximate algorithms +# exist to compute optimal or near optimal bounding boxes for sets of points. +# +# +# +# +# Qualifier for the shape of each hexahedron. +# +# +# +# +# +# +# +# +# Qualifier that is useful in cases when one edge is longer than all other +# edges of the hexahedra. Often the term length is associated with the +# assumption that one edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the horizontal +# direction assuming a specific coordinate system. +# +# For the sake of explicitness quantities like length, width, and height +# should not be reported without specifying also the assumed reference frame. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the vertical +# direction assuming a specific coordinate system. +# +# +# +# +# +# +# +# Volume of each hexahedron. +# +# +# +# +# +# +# +# Total (surface) 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 coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all hexahedra. +# +# +# +# +# Individual storage of each hexahedron. +# +# +# +# +# Individual storage of each hexahedron as a graph. +# +# +# diff --git a/base_classes/nyaml/NXcg_parallelogram.yaml b/base_classes/nyaml/NXcg_parallelogram.yaml new file mode 100644 index 0000000000..ab6ec8ab40 --- /dev/null +++ b/base_classes/nyaml/NXcg_parallelogram.yaml @@ -0,0 +1,172 @@ +category: base +doc: | + Computational geometry description of a set of parallelograms. + + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: + + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. + + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. + + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing 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, i.e. + most tightly 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 an optimal bounding box to a point set 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. +type: group +NXcg_parallelogram(NXcg_primitive): + + # qualifiers and properties of parallelograms + is_rectangle(NX_BOOLEAN): + doc: | + To specify which parallelogram is a rectangle. + dimensions: + rank: 1 + dim: (c,) + is_axis_aligned(NX_BOOLEAN): + doc: | + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. + dimensions: + rank: 1 + dim: (c,) + + # detailed mesh-based representation + parallelograms(NXcg_face_list_data_structure): + doc: | + Combined storage of all parallelograms. + parallelogramID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of each parallelogram. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 925993111384a8a2e209475675f51f560114d21c32b9ed50c5f4f8db413a87af +# +# +# +# +# +# +# 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. +# +# This class can also be used to describe rectangles or squares, irrespective +# whether these are axis-aligned or not. The class represents different +# access and description levels to embrace applied scientists and computational +# geometry experts with their different views: +# +# * The simplest case is the communication of dimensions aka the size of a +# region of interest in the 2D plane. In this case, communicating the +# alignment with axes is maybe not as relevant as it is to report the area +# of the ROI. +# * In other cases the extent of the parallelogram is relevant though. +# * Finally, in CAD models it should be possible to specify the polygons +# which the parallelograms represent with exact numerical details. +# +# Parallelograms are important geometrical primitives as their usage for +# describing many scanning experiments shows where typically parallelogram-shaped +# ROIs are scanned across the surface of a sample. +# +# The term parallelogram will be used throughout this base class thus including +# the important special cases rectangle, square, 2D box, axis-aligned bounding box +# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D +# counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a rectangle whose edges are aligned with the +# axes of a coordinate system. As a part of binary trees AABBs are important data +# objects for executing 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, i.e. +# most tightly 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 an optimal bounding box to a point set in 2D. +# +# +# +# +# To specify which parallelogram is a rectangle. +# +# +# +# +# +# +# +# Only to be used if is_rectangle is present. In this case, this field +# describes whether parallelograms are rectangles whose primary edges +# are parallel to the axes of the coordinate system. +# +# +# +# +# +# +# +# +# Combined storage of all parallelograms. +# +# +# +# +# Individual storage of each parallelogram. +# +# +# diff --git a/base_classes/nyaml/NXcg_point.yaml b/base_classes/nyaml/NXcg_point.yaml new file mode 100644 index 0000000000..33db7ec47b --- /dev/null +++ b/base_classes/nyaml/NXcg_point.yaml @@ -0,0 +1,139 @@ +category: base +doc: | + Computational geometry description of a set of points. + + Points may have an associated time value. Users are advised though to store + time data of point sets rather as instances of time events, where for each + point in time there is an :ref:`NXcg_point` 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 (real time or + simulated physical time). Thereby, the storage of redundant timestamp + information per point is considered as obsolete. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality. + c: | + The cardinality of the set, i.e. the number of points. +type: group +NXcg_point(NXcg_primitive): + position(NX_NUMBER): + unit: NX_ANY + doc: | + Coordinates of the points. + dimensions: + rank: 2 + dim: (c, d) + time(NX_NUMBER): + unit: NX_TIME + doc: | + (Elapsed) time for each point. + + If the field time is needed contextualize the time_offset relative to which + time values are defined. Alternative store timestamp. + dimensions: + rank: 1 + dim: (c,) + timestamp(NX_DATE_TIME): + doc: | + ISO8601 with local time zone offset for each point. + dimensions: + rank: 1 + dim: (c,) + time_offset(NX_DATE_TIME): + doc: | + ISO8601 with local time zone offset that serves as the reference + for values in the field time. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 14c313890564590cf516821eca33c4e26bed72d15a8078e0dc52a5bff904ad30 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality. +# +# +# +# +# The cardinality of the set, i.e. the number of points. +# +# +# +# +# Computational geometry description of a set of points. +# +# Points may have an associated time value. Users are advised though to store +# time data of point sets rather as instances of time events, where for each +# point in time there is an :ref:`NXcg_point` 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 (real time or +# simulated physical time). Thereby, the storage of redundant timestamp +# information per point is considered as obsolete. +# +# +# +# Coordinates of the points. +# +# +# +# +# +# +# +# +# (Elapsed) time for each point. +# +# If the field time is needed contextualize the time_offset relative to which +# time values are defined. Alternative store timestamp. +# +# +# +# +# +# +# +# ISO8601 with local time zone offset for each point. +# +# +# +# +# +# +# +# ISO8601 with local time zone offset that serves as the reference +# for values in the field time. +# +# +# diff --git a/base_classes/nyaml/NXcg_polygon.yaml b/base_classes/nyaml/NXcg_polygon.yaml new file mode 100644 index 0000000000..5b6b1f7ff0 --- /dev/null +++ b/base_classes/nyaml/NXcg_polygon.yaml @@ -0,0 +1,217 @@ +category: base + +# similar design like NXoff_geometry but easier to understand +doc: | + Computational geometry description of a set of polygons in Euclidean space. + + Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design their own base class + e.g. NXcg_polytope to describe such even more complex primitives instead + of abusing this base class for such purposes. +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. +type: group +NXcg_polygon(NXcg_primitive): + number_of_total_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of vertices in the set. + + # detailed mesh-based representation + polygons(NXcg_face_list_data_structure): + doc: | + Combined storage of all primitives of all polygons. + polygonID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of the mesh of each polygon. + polygon_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial + doc: | + Individual storage of each polygon as a graph. + + # properties of the polygon primitives + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + For each polygon its accumulated length along its edges. + dimensions: + rank: 1 + dim: (c,) + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Interior angles for each polygon. There are as many values per polygon + as there are 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. + dimensions: + rank: 1 + dim: (n_total,) + shape(NX_INT): + unit: NX_UNITLESS + doc: | + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + dimensions: + rank: 1 + dim: (c,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f2c9dd98d7dba9d3f888b529c0af25ebea924039fc745bdeb51cc97b9443fa5b +# +# +# +# +# +# +# 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed +# polyhedra. Even more general complexes can be thought of. An example are the +# so-called piecewise-linear complexes used in the TetGen library. +# +# As these complexes can have holes though, polyhedra without holes are one +# subclass of such complexes, users should rather design their own base class +# e.g. NXcg_polytope to describe such even more complex primitives instead +# of abusing this base class for such purposes. +# +# +# +# The total number of vertices in the set. +# +# +# +# +# +# Combined storage of all primitives of all polygons. +# +# +# +# +# Individual storage of the mesh of each polygon. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# +# +# +# For each polygon its accumulated length along its edges. +# +# +# +# +# +# +# +# Interior angles for each polygon. There are as many values per polygon +# as there are 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 +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_polyhedron.yaml b/base_classes/nyaml/NXcg_polyhedron.yaml new file mode 100644 index 0000000000..c591e07215 --- /dev/null +++ b/base_classes/nyaml/NXcg_polyhedron.yaml @@ -0,0 +1,170 @@ +category: base +doc: | + Computational geometry description of a set of polyhedra in Euclidean space. + + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. + + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon`. +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. +type: group +NXcg_polyhedron(NXcg_primitive): + + # qualifiers and properties of polyhedra + number_of_faces(NX_UINT): + unit: NX_UNITLESS + doc: | + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. + dimensions: + rank: 1 + dim: (c,) + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of faces. + dimensions: + rank: 1 + dim: (n_f_total,) + number_of_edges(NX_UINT): + doc: | + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counted for each polyhedron. + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of each edge. + dimensions: + rank: 1 + dim: (n_e_total,) + + # detailed mesh-based representation + polyhedra(NXcg_face_list_data_structure): + doc: | + Combined storage of all primitives of all polyhedra. + polyhedronID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of each polyhedron. + polyhedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial + doc: | + Individual storage of each polygon as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d7fb29aff4740eed151d11ee4c352507406b734ab3e56f56c58b9079918ad461 +# +# +# +# +# +# +# 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 set of polyhedra in Euclidean space. +# +# Polyhedra or so-called cells (especially in the convex of tessellations) are +# constructed from polygon meshes. Polyhedra may make contact to allow a usage +# of this base class for a description of tessellations. +# +# For the description of more complicated manifolds and especially for polyhedra +# with holes, users are advised to check if their particular needs are described +# by creating customized instances of an :ref:`NXcg_polygon`. +# +# +# +# +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. +# +# +# +# +# +# +# +# Area of each of faces. +# +# +# +# +# +# +# +# The number of edges for each polyhedron. Edges of adjoining polyhedra +# are counted for each polyhedron. +# +# +# +# +# Length of each edge. +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all polyhedra. +# +# +# +# +# Individual storage of each polyhedron. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# diff --git a/base_classes/nyaml/NXcg_polyline.yaml b/base_classes/nyaml/NXcg_polyline.yaml new file mode 100644 index 0000000000..26e3a753e1 --- /dev/null +++ b/base_classes/nyaml/NXcg_polyline.yaml @@ -0,0 +1,238 @@ +category: base +doc: | + Computational geometry description of a set of polylines. + + 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 traversal along the polyline when + walking from the first to the 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. +type: group +NXcg_polyline(NXcg_primitive): + depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcg_point` which defines the + location of the vertices that are referred to in this + NXcg_polyline instance. + number_of_unique_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of vertices that have different positions. + number_of_total_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of vertices, irrespective of their eventual uniqueness. + number_of_vertices(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. + dimensions: + rank: 1 + dim: (c,) + + # 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. + vertices(NX_NUMBER): + unit: NX_ANY + doc: | + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique positions and vertices + as this often supports with storing geometry data more efficiently. + 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 stores each vertex of a triangle mesh + even though many vertices are shared between triangles and thus + storing multiple copies of their positions is redundant. + dimensions: + rank: 2 + dim: (n_v, 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 several times. + polylines(NX_INT): + unit: NX_UNITLESS + doc: | + Sequence of identifier for vertices how they build each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet at a vertex (assume for example that the second vertex + is shared and marking the junction between the two polylines), it is possible + that there are only five unique positions. This suggests to store five + unique vertices. + + A non-trivial example is a set with several polylines. Assume that each + has a different number of vertices. The array stores the identifier of + the vertices in the sequence how the polylines are visited: + + The first entry is the identifier of the first vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the first polyline. + Thereafter, the first vertex of the second polyline, and so on and so forth. + Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), + the vertices of the N-th polyline can be accessed on the array + index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. + dimensions: + rank: 1 + dim: (n_total,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b14cc08d68ff1d70e5adca4bb17904235e53d9c9d2fd6c3aa5438efa188a2fed +# +# +# +# +# +# +# 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. +# +# 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 traversal along the polyline when +# walking from the first to the last vertex. +# +# +# +# Reference to an instance of :ref:`NXcg_point` which defines the +# location of the vertices that are referred to in this +# NXcg_polyline instance. +# +# +# +# +# The total number of vertices that have different positions. +# +# +# +# +# The total number of vertices, irrespective of their eventual uniqueness. +# +# +# +# +# The total number of vertices of each polyline, irrespectively +# whether vertices are shared by vertices or not. +# +# +# +# +# +# +# +# +# Positions of the vertices which support the members of the polyline set. +# +# Users are encouraged to reduce the vertices to unique positions and vertices +# as this often supports with storing geometry data more efficiently. +# 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 stores each vertex of a triangle mesh +# even though many vertices are shared between triangles and thus +# storing multiple copies of their positions is redundant. +# +# +# +# +# +# +# +# +# If true indicates that the vertices are all placed at different +# positions and have different identifiers, i.e. no points overlap +# or are counted several times. +# +# +# +# +# Sequence of identifier for vertices how they build each polyline. +# +# A trivial example is a set with two polylines with three vertices each. +# If the polylines meet at a vertex (assume for example that the second vertex +# is shared and marking the junction between the two polylines), it is possible +# that there are only five unique positions. This suggests to store five +# unique vertices. +# +# A non-trivial example is a set with several polylines. Assume that each +# has a different number of vertices. The array stores the identifier of +# the vertices in the sequence how the polylines are visited: +# +# The first entry is the identifier of the first vertex of the first polyline, +# followed by the second vertex of the first polyline, until the last vertex +# of the first polyline. +# Thereafter, the first vertex of the second polyline, and so on and so forth. +# Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), +# the vertices of the N-th polyline can be accessed on the array +# index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_primitive.yaml b/base_classes/nyaml/NXcg_primitive.yaml new file mode 100644 index 0000000000..bb8b776909 --- /dev/null +++ b/base_classes/nyaml/NXcg_primitive.yaml @@ -0,0 +1,432 @@ +category: base +doc: | + Computational geometry description of a set of primitives in Euclidean space. + + Primitives must neither be degenerated nor self-intersect. + Individual primitives can differ in their properties (e.g. size, shape, rotation). +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the embedding space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive(NXobject): + depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + doc: | + The dimensionality of the primitive set with value up to d. + enumeration: + + # add when 1521 has been merged open="true" + items: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + doc: | + The cardinality of the primitive set. Value should be equal to c. + index_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Indices can be used as identifiers and thus names of instances. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + index_offset and cardinality. For example if identifier run from + -2 to 3 the value for index_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where index_offset is 1 and 0 respectively. + indices(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dimensions: + rank: 1 + dim: (c,) + center(NX_NUMBER): + unit: NX_ANY + doc: | + The center of each primitive + dimensions: + rank: 2 + dim: (c, d) + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dimensions: + rank: 1 + dim: (c,) + shape(NX_NUMBER): + unit: NX_LENGTH + doc: | + Shape of each primitive + dimensions: + rank: 2 + dim: (c, d) + length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + dimensions: + rank: 1 + dim: (c,) + width(NX_NUMBER): + unit: NX_LENGTH + doc: | + Width of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + dimensions: + rank: 1 + dim: (c,) + height(NX_NUMBER): + unit: NX_LENGTH + doc: | + Height of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + dimensions: + rank: 1 + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dimensions: + rank: 1 + dim: (c,) + volume(NX_NUMBER): + unit: NX_ANY + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + Volume is an N-D concept for values of dimensionality larger than 1, + Area is an alias for the two-dimensional case. + dimensions: + rank: 1 + dim: (c,) + area(NX_NUMBER): + unit: NX_AREA + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + dimensions: + rank: 1 + dim: (c,) + orientation(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Direction unit vector which points along the + longest principal axis of each primitive. + + Use the depends_on attribute to specify in which coordinate system + these direction unit vectors are defined. + dimensions: + rank: 2 + dim: (c, d) + is_mesh(NX_BOOLEAN): + doc: | + Do the primitives define a mesh. + is_triangle_mesh(NX_BOOLEAN): + doc: | + Do the primitives define a triangle mesh or not. + is_surface_mesh(NX_BOOLEAN): + doc: | + Do the primitives discretize the surface of an object or not. + is_geodesic_mesh(NX_BOOLEAN): + doc: | + Do the primitives define a geodesic mesh or not. + + A geodesic surface mesh is a triangulated surface mesh with metadata which + can be used as an approximation to describe the surface of a sphere. + Triangulation of spheres are commonly used in Materials Science + for quantifying texture of materials, i.e. the relative rotation of + crystals to sample directions. + + For additional details or an introduction into the topic of geodesic meshes + see (from which specifically the section on subdivision schemes is relevant). + + * `E. S. Popko and C. J. Kitrick `_ + + Earth scientists 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 software. For now we propose to use this + base class as a container for organizing data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + e.g. a geodesic (surface) mesh was instantiated as there are many + possibilities to do so. + description: + doc: | + Possibility to store details such as when primitives form a (specific) type + of mesh such as geodesic meshes. + vertex_normal(NXcg_unit_normal): + edge_normal(NXcg_unit_normal): + face_normal(NXcg_unit_normal): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 65f66dd89993d2350d6905134228c02bcc0bb2608e12fadfd29b8e2730de164a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the embedding space. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of primitives in Euclidean space. +# +# Primitives must neither be degenerated nor self-intersect. +# Individual primitives can differ in their properties (e.g. size, shape, rotation). +# +# +# +# Reference to an instance of :ref:`NXcoordinate_system` in which these primitives +# are defined. +# +# +# +# +# The dimensionality of the primitive set with value up to d. +# +# +# +# +# +# +# +# +# +# +# The cardinality of the primitive set. Value should be equal to c. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the set differs from zero. +# +# Indices can be used as identifiers and thus names of instances. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# index_offset and cardinality. For example if identifier run from +# -2 to 3 the value for index_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where index_offset is 1 and 0 respectively. +# +# +# +# +# Identifier of each member for explicit indexing. +# +# +# +# +# +# +# +# The center of each primitive +# +# +# +# +# +# +# +# +# True if the center is a center of mass. +# +# +# +# +# +# +# +# Shape of each primitive +# +# +# +# +# +# +# +# +# Length of each primitive +# +# Often the term is associated with the assumption that one +# edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Width of each primitive +# +# Often the term is associated with the assumption that one +# edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Height of each primitive +# +# Often the term is associated with the assumption that one +# edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# True if primitive is closed such that it has properties like area or volume. +# +# +# +# +# +# +# +# Volume of each primitive. +# +# Set to NaN if does not apply for primitives for which is_closed is False. +# Volume is an N-D concept for values of dimensionality larger than 1, +# Area is an alias for the two-dimensional case. +# +# +# +# +# +# +# +# Alias for surface_area of each primitive. +# +# Set to NaN if does not apply for primitives for which is_closed is False. +# +# +# +# +# +# +# +# Direction unit vector which points along the +# longest principal axis of each primitive. +# +# Use the depends_on attribute to specify in which coordinate system +# these direction unit vectors are defined. +# +# +# +# +# +# +# +# +# Do the primitives define a mesh. +# +# +# +# +# Do the primitives define a triangle mesh or not. +# +# +# +# +# Do the primitives discretize the surface of an object or not. +# +# +# +# +# Do the primitives define a geodesic mesh or not. +# +# A geodesic surface mesh is a triangulated surface mesh with metadata which +# can be used as an approximation to describe the surface of a sphere. +# Triangulation of spheres are commonly used in Materials Science +# for quantifying texture of materials, i.e. the relative rotation of +# crystals to sample directions. +# +# For additional details or an introduction into the topic of geodesic meshes +# see (from which specifically the section on subdivision schemes is relevant). +# +# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ +# +# Earth scientists 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 software. For now we propose to use this +# base class as a container for organizing data related to geodesic meshes. +# +# Specifically an instance of this base class should detail the rule set how +# e.g. a geodesic (surface) mesh was instantiated as there are many +# possibilities to do so. +# +# +# +# +# Possibility to store details such as when primitives form a (specific) type +# of mesh such as geodesic meshes. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_roi.yaml b/base_classes/nyaml/NXcg_roi.yaml new file mode 100644 index 0000000000..21180b2c9c --- /dev/null +++ b/base_classes/nyaml/NXcg_roi.yaml @@ -0,0 +1,77 @@ +category: base +doc: | + Base class for a region-of-interest (ROI) bound by geometric primitives. + + So-called region-of-interest(s) (ROIs) are typically used to describe a + region in space (and time) where an observation is made or for which + a computer simulation is performed with given boundary conditions. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to + define explicitly the reference frame in which the primitives are + defined. + +# eventually redundant NXsolid_geometry? +type: group +NXcg_roi(NXobject): + (NXcg_ellipsoid): + (NXcg_cylinder): + (NXcg_parallelogram): + (NXcg_hexahedron): + (NXcg_polyhedron): + + # how to handle cases where multiple primitives should be included? + # see comment to NXcg_triangle roi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3227a9f16fd3ed1e325ec7ccb157fea7397a3855d2664809641eff45bd83caad +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to +# define explicitly the reference frame in which the primitives are +# defined. +# +# +# +# Base class for a region-of-interest (ROI) bound by geometric primitives. +# +# So-called region-of-interest(s) (ROIs) are typically used to describe a +# region in space (and time) where an observation is made or for which +# a computer simulation is performed with given boundary conditions. +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_tetrahedron.yaml b/base_classes/nyaml/NXcg_tetrahedron.yaml new file mode 100644 index 0000000000..270684044b --- /dev/null +++ b/base_classes/nyaml/NXcg_tetrahedron.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + Computational geometry description of a set of tetrahedra. + + Among hexahedral elements, tetrahedral elements are one of the most + frequently used geometric primitive for meshing and describing volumetric + objects in continuum-field simulations. +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. +type: group +NXcg_tetrahedron(NXcg_primitive): + + # qualifiers and properties of tetrahedra + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of the four triangular faces of each tetrahedron. + dimensions: + rank: 2 + dim: (c, 4) + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of each edge of each tetrahedron. + dimensions: + rank: 2 + dim: (c, 6) + tetrahedra(NXcg_face_list_data_structure): + doc: | + Combined storage of all primitives of all tetrahedra. + tetrahedronID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of each tetrahedron. + tetrahedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial + doc: | + Individual storage of each tetrahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f772d6a0bf5b431dc18eb9da83598d71137a3c858351d4290df0a101c89759e5 +# +# +# +# +# +# +# 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. +# +# Among hexahedral elements, tetrahedral elements are one of the most +# frequently used geometric primitive for meshing and describing volumetric +# objects in continuum-field simulations. +# +# +# +# +# Area of each of the four triangular faces of each tetrahedron. +# +# +# +# +# +# +# +# +# Length of each edge of each tetrahedron. +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all tetrahedra. +# +# +# +# +# Individual storage of each tetrahedron. +# +# +# +# +# Individual storage of each tetrahedron as a graph. +# +# +# diff --git a/base_classes/nyaml/NXcg_triangle.yaml b/base_classes/nyaml/NXcg_triangle.yaml new file mode 100644 index 0000000000..0654914fac --- /dev/null +++ b/base_classes/nyaml/NXcg_triangle.yaml @@ -0,0 +1,145 @@ +category: base +doc: | + Computational geometry description of a set of triangles. +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. +type: group +NXcg_triangle(NXcg_primitive): + number_of_unique_vertices(NX_INT): + unit: NX_UNITLESS + doc: | + Number of unique vertices in the triangle set. + triangles(NXcg_face_list_data_structure): + doc: | + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. + triangleID(NXcg_face_list_data_structure): + nameType: partial + doc: | + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. + dimensions: + rank: 2 + dim: (c, 3) + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. + dimensions: + rank: 2 + dim: (c, 3) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fe99956b8b305e0e920fc7b726b5f8ed243fefa82c6ebb87f13e1ce8cdebef9d +# +# +# +# +# +# +# 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. +# +# +# +# Number of unique vertices in the triangle set. +# +# +# +# +# Combined storage of all primitives of all triangles. +# +# This description resembles the typical representation of primitives +# in file formats such as OFF, PLY, VTK, or STL. +# +# +# +# +# Individual storage of each triangle. +# Users are advised that using such individual storage of primitives +# may be less storage efficient than creating a combined storage. +# +# +# +# +# Length of the edges of each triangle. +# +# For each triangle values are reported via traversing +# the vertices in the sequence as these are defined. +# +# +# +# +# +# +# +# +# Interior angles of each triangle. +# +# For each triangle values are reported for the angle opposite +# to the respective edges in the sequence how vertices are defined. +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcg_unit_normal.yaml b/base_classes/nyaml/NXcg_unit_normal.yaml new file mode 100644 index 0000000000..16e3be34d6 --- /dev/null +++ b/base_classes/nyaml/NXcg_unit_normal.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + Computational geometry description of a set of (oriented) unit normal vectors. + + Store normal vector information as properties of primitives. + Use only only as a child of an instance of :ref:`NXcg_primitive` + so that this instance acts as the parent to define a context. + +# eventually remove this base class and make normal vector a property of the primitive +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. + +# 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 +type: group +NXcg_unit_normal(NXobject): + normals(NX_NUMBER): + unit: NX_LENGTH + doc: | + Direction of each normal - a unit normal. + dimensions: + rank: 2 + dim: (c, d) + orientation(NX_INT): + unit: NX_UNITLESS + doc: | + An indicator which details the orientation of each normal vector + in relation to its primitive, assuming the object is viewed + from a position outside the object. + + * 0 - undefined + * 1 - outer unit normal vector + * 2 - inner unit normal vector + dimensions: + rank: 1 + dim: (c,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f987a47e06d87c7a3835affeda661ac97e7939eb67c9775e11698bc408a0b88e +# +# +# +# +# +# +# +# +# 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. +# +# Store normal vector information as properties of primitives. +# Use only only as a child of an instance of :ref:`NXcg_primitive` +# so that this instance acts as the parent to define a context. +# +# +# +# Direction of each normal - a unit normal. +# +# +# +# +# +# +# +# +# An indicator which details the orientation of each normal vector +# in relation to its primitive, assuming the object is viewed +# from a position outside the object. +# +# * 0 - undefined +# * 1 - outer unit normal vector +# * 2 - inner unit normal vector +# +# +# +# +# +# diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index 2c3c5f3460..faca9e7310 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -1,4 +1,4 @@ - + + + + + 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 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. + + + + + 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 specializes :ref:`NXoptical_spectroscopy` by + extending the terms and setting specific requirements. + + 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 + + + + + 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. + + + + + + + + + + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + + + + + + + + Specify the type of ellipsometry. + + + + + + + + + + + + + Properties of the ellipsometry equipment. + + + + What type of ellipsometry was used? See Fujiwara Table 4.2. + + + + + + + + + + + + + + + + + + + If focusing probes (lenses) were used, please state if the data + were corrected for the window effects. + + + + + + + + + + + + + Were the recorded data corrected by the window effects of the + focusing probes (lenses)? + + + + + Specify the angular spread caused by the focusing probes. + + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + + + Define which element rotates, e.g. polarizer or analyzer. + + + + + + + + + + + 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. + + + + + + + + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + + + + + + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better + directly in the location of the sample positioner or temperature sensor. + + + + 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). + + + + + + + + :ref:`External link <Design-Links>` to the data field in 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. + + Ideally, the link uses the relative path with respect to the actual + NeXus file. + + + + + + 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. + + + + + + diff --git a/applications/NXoptical_spectroscopy.nxdl.xml b/applications/NXoptical_spectroscopy.nxdl.xml new file mode 100644 index 0000000000..cc22ff38f8 --- /dev/null +++ b/applications/NXoptical_spectroscopy.nxdl.xml @@ -0,0 +1,1075 @@ + + + + + + + + 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 measurements (1st dimension of measured data arrays). 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. + + + + + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. + + For any free-text descriptions, it is recommended to use English, as this ensures + the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. + + + + + 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. + + + + + + + + + + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise, the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + + + + + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + + + + + + An optional free-text description of the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. + + + + + Specify the type of the optical experiment. + + Use another term if none of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. + + + + + + + + + + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. + + + + + + + + + + + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. + + + + + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. + + + + + + + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. + + + + + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). + + + + + + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation + + + + + Devices or elements of the optical spectroscopy setup described with its + properties and general information. + + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties + + + + This can be used to describe properties of a photon beam. + A beam can be connected to components, via their + "inputs" and "outputs". + + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are actually measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) + + + + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). + + + + + + + + + + + + + The path to the device which emitted this beam (light source or frequency doubler). + + This parameter is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light source can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". + + Example: /entry/instrument/source_532nmlaser + + + + + + + + + + + + + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. Note that the zero reference should be a direction vector for a + :ref:`reference_plane </NXbeam/TRANSFORMATIONS/reference_plane-field>` + normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. + This can be used if no definition of respective + coordinate systems for beam and sample normal is done. If coordinate systems + are defined, refer to beam "incident_polarization". + + + + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + + + + + + + + + Raw data before calibration. + + + + + + Specify respective hardware which was used for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). + + + + + + + + + + + + + + + + + + + + + + + + + + + If available, name/ID/norm of the light source standard. + + + + + Details about the device information. + + + + + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" together with this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + + + + + + + + + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is possible as well: + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam + - angle of in-plane sample rotation (direction along the sample's surface normal) + + + + + + + + + Angle between sample incident beam and sample surface. + + + + + Angle between incident and detection beam + + + + + Sample tilt between sample normal, and the plane spanned by detection and + incident beam. + + + + + Inplane rotation of the sample, with rotation axis along sample normal. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. These two directions span the plane + of incidence. + + + + + 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. + These two directions span the plane of detection. + + + + + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + + + + + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + + + + + Set of transformations, describing the relative orientation of different + parts of the experiment (beams or sample). You may select one of the specified + angles for incident and detection beam or sample, and then use polar and azimuthal + angles to define the direction via spherical coordinates. + This allows consistent definition between different coordinate system. + You may refer to self defined coordinate system as well. + + + If "angle_reference_frame = beam centered", then this coordinate system is used: + McStas system (NeXus default) + (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) + + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and + the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` + is vertically oriented. + + If "angle_reference_frame = sample-normal centered", then this coordinate + system is used + z - math:`[0,0,1]` along sample surface normal + x - math:`[1,0,0]` defined by sample surface projected incident beam. + y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. + For this case, x may be ill defined, if the incident beam is perpendicular + to the sample surface. In this case, use the beam centered description. + + + + + + + + + + + Rotation about the y axis (polar rotation within the sample plane). + + + + + + + + + + + + + + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. + + + + + + Rotation about the z axis (azimuthal rotation within the sample plane). + + + + + + + + + + + + + + + + + + + + + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + + + + + Optical components along the optical beam path. + + Every object which interacts or modifies optical beam properties, + may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + + + + This is the optical element used to focus or collect light. This may + be a generic lens or microcope objectives which are used for the + Raman scattering process. + + + + + + + + + + + + + + + + Polarization filter to prepare light to be measured or to be incident + on the sample. + Generic polarization filter properties may be implemented via NXfilter_pol + at a later stage. + + + + Physical principle of the polarization filter used to create a + defined incident or scattered light state. + + + + + + + + + + + Specific name or type of the polarizer used. + + Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston + Polarizer... + + + + + + + Spectral filter used to modify properties of the scattered or incident light. + + + + Type of laser-line filter used to suppress the laser, if measurements + close to the laser-line are performed. + + + + Blocks shorter wavelengths and transmits longer wavelengths. + + + Blocks longer wavelengths and transmits shorter wavelengths. + + + Blocks a narrow wavelength band while transmitting others. + + + Reflects certain wavelength ranges instead of absorbing them. + + + Reduces light intensity uniformly across all wavelengths. + + + + + + Type of laser-line filter used to suppress the laser, if measurements + close to the laser-line are performed. + + + + + + + + + + + Properties of the spectral filter such as wavelength dependent transmission + or reflectivity. + + + + Which property is used to form the spectral properties of light, + i.e. transmission or reflection properties. + + + + + + + + + + + + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. + + + + + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. + + + + Specify the type of the sample stage. + + + + + + + + + + + + + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. + + + + + Description of relation of the beam with the sample. How does the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + This is redundant if a full orientation description is done via the + stage's "transformations" entry. + + + + + + + + + + + + + + + + + + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. + + + + + + + + + + + + + + + + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + + + + + + + + + + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + + + + 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. + + + + + Description of the software by persistent resource, where the program, + code, script etc. can be found. + + + + + + + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. + + + + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + + + + + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + calibration_time. + + + + + + + + + + + + If calibration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. + + + + + + The overall resolution of the optical instrument. + + + + + + + + + + Minimum distinguishable wavelength separation of peaks in spectra. + + + + + + + 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. + + + + + Locally unique ID of the sample, used in the research institute or group. + + + + + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. + + + + + Free text description of the sample. + + + + + 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'. + + + + + 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 timestamp when + the measured specimen surface was actively prepared. + + + + + A set of activities that occurred to the sample prior to/during the experiment. + + + + + Sample temperature (either controlled or just measured). + + + + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. + + + + + + + + + + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + + + + + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + + + + + Device for cooling the sample (Cryostat, Airflow cooler, etc.). + This should be a link to /entry/instrument/manipulator/cryostat. + + + + + + Arbitrary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperature description of the sample. + + + + Medium, in which the sample is placed. + + + + + + + + + + + + + + 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. + + + + + + + + + + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + 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. + + + + + If a thickness if given, please specify how this thickness was estimated or + determined. + + + + + 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. + + + + + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. + + + + + If the sample is grown or fixed on a substrate, specify this here by + a free text description. + + + + + + Here generic types of data may be saved. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plottable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). + + You may provide multiple instances of NXdata + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) + + + + + + + + Calibrated wavelength axis. + + + + + + + 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. + + + + + + + diff --git a/applications/NXraman.nxdl.xml b/applications/NXraman.nxdl.xml new file mode 100644 index 0000000000..5bfe38e325 --- /dev/null +++ b/applications/NXraman.nxdl.xml @@ -0,0 +1,205 @@ + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Number of scattering configurations used in the measurement. + It is 1 for only parallel polarization measurement, 2 for parallel and cross + polarization measurement or larger, if i.e. the incident and scattered photon + direction is varied. + + + + + An application definition for Raman spectroscopy experiments. + + This application definition supports a wide range of Raman spectroscopy experiments. + These may be as simple as acquiring a single Raman spectrum from spontaneous Raman + scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also + includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant + Raman scattering, and multidimensional Raman spectra collected under varying conditions + such as temperature, pressure, or electric field. + + The application definition comprises two main components: + + 1. Structures defined in NXoptical_spectroscopy: + * Instrument configuration and data calibration + * Sensors monitoring sample or beam conditions + + 2. Structures specified and extended in NXraman: + * Description of the experiment type + * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) + * Detailed description of beam properties and their interaction with the sample + * Sample-specific information + + Information on Raman spectroscopy are provided in: + + General + + * Lewis, Ian R.; Edwards, Howell G. M. + Handbook of Raman Spectroscopy + ISBN 0-8247-0557-2 + + Raman scattering selection rules + + * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. + Group Theory - Application to the Physics ofCondensed Matter + ISBN 3540328971 + + Semiconductors + + * Manuel Cardona + Light Scattering in Solids I + eBook ISBN: 978-3-540-37568-5 + DOI: https://doi.org/10.1007/978-3-540-37568-5 + + * Manuel Cardona, Gernot Güntherodt + Light Scattering in Solids II + eBook ISBN: 978-3-540-39075-6 + DOI: https://doi.org/10.1007/3-540-11380-0 + + * See as well other Books from the "Light Scattering in Solids" series: + III: Recent Results + IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects + V: Superlattices and Other Microstructures + VI: Recent Results, Including High-Tc Superconductivity + VII: Crystal-Field and Magnetic Excitations + VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons + IX: Novel Materials and Techniques + + Glasses, Liquids, Gasses, ... + + Review articles: + Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, + Surface-enhanced Raman scattering, Tip-enhanced Raman scattering + * https://doi.org/10.1186/s11671-019-3039-2 + + + + + An application definition for Raman spectroscopy. + + + + 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. + + + + + + + + + + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + + + + + + + + Specify the type of Raman experiment. + + + + + + + + + + + + + + + + + + Metadata of the setup, its optical elements and physical properties which + defines the Raman measurement. + + + + Scattering configuration as defined by the porto notation by three + states, which are orthogonal to each other. Example: z(xx)z for + parallel polarized backscattering configuration. + + See: + https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman + + A(BC)D + + A = The propagation direction of the incident light (k_i) + B = The polarization direction of the incident light (E_i) + C = The polarization direction of the scattered light (E_s) + D = The propagation direction of the scattered light (k_s) + + An orthogonal base is assumed. + Linear polarized light is displayed by e.g. "x","y" or "z" + Unpolarized light is displayed by "." + For non-orthogonal vectors, use the attribute porto_notation_vectors. + + + + Scattering configuration as defined by the porto notation given by + respective vectors. + + Vectors in the porto notation are defined as for A, B, C, D above. + Linear light polarization is assumed. + + + + 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. + A has to be perpendicular to B and C perpendicular to D. + + + + + + + + + + Beam which is incident to the sample. + + + + + + diff --git a/applications/nyaml/NXellipsometry.yaml b/applications/nyaml/NXellipsometry.yaml new file mode 100644 index 0000000000..97786dfd38 --- /dev/null +++ b/applications/nyaml/NXellipsometry.yaml @@ -0,0 +1,669 @@ +category: application +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 specializes :ref:`NXoptical_spectroscopy` by + extending the terms and setting specific requirements. + + 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 or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + 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. +type: group +NXellipsometry(NXoptical_spectroscopy): + (NXentry): + 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] + title: + exists: recommended + experiment_type: + doc: | + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + enumeration: [ellipsometry] + ellipsometry_experiment_type: + doc: | + Specify the type of ellipsometry. + enumeration: + open_enum: true + items: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry] + (NXinstrument): + doc: | + Properties of the ellipsometry equipment. + ellipsometer_type: + doc: | + What type of ellipsometry was used? See Fujiwara Table 4.2. + enumeration: + open_enum: true + items: [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] + focusing_probes(NXoptical_lens): + exists: optional + doc: | + If focusing probes (lenses) were used, please state if the data + were corrected for the window effects. + type: + enumeration: + open_enum: true + items: [objective, lens, glass fiber, none] + device_information(NXfabrication): + exists: optional + data_correction(NX_BOOLEAN): + exists: recommended + doc: | + Were the recorded data corrected by the window effects of the + focusing probes (lenses)? + angular_spread(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Specify the angular spread caused by the focusing probes. + rotating_element(NXwaveplate): + doc: | + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + 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)] + revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + 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. + fixed_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + 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). + max_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Specify the maximum value of revolutions of the rotating element + for each measurement. + (NXsample): + backside_roughness(NX_BOOLEAN): + exists: optional + doc: | + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + data_collection(NXdata): + exists: optional + doc: | + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better + directly in the location of the sample positioner or temperature sensor. + data_identifier(NX_NUMBER): + exists: recommended + 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: + exists: recommended + 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): + nameType: partial + exists: optional + unit: NX_ANY + 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. + dimensions: + rank: 1 + dim: (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): + unit: NX_ANY + 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. + dimensions: + rank: 3 + dim: (N_measurements, N_observables, 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 + unit: NX_ANY + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + dimensions: + rank: 3 + dim: (N_measurements, N_observables, 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: (N_sensors,) + reference_data_link: + exists: optional + doc: | + :ref:`External link ` to the data field in 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. + + Ideally, the link uses the relative path with respect to the actual + NeXus file. + data_software(NXprogram): + exists: optional + program: + exists: recommended + 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: + exists: recommended + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 439c6e2ace0f16356ed2af0b01104ee3c32601f1496bdccd29c90c8f266796e9 +# +# +# +# +# +# +# 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 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. +# +# +# +# +# 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 specializes :ref:`NXoptical_spectroscopy` by +# extending the terms and setting specific requirements. +# +# 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 +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Specify the type of the optical experiment. +# +# You may specify fundamental characteristics or properties in the experimental sub-type. +# +# +# +# +# +# +# +# Specify the type of ellipsometry. +# +# +# +# +# +# +# +# +# +# +# +# +# Properties of the ellipsometry equipment. +# +# +# +# What type of ellipsometry was used? See Fujiwara Table 4.2. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If focusing probes (lenses) were used, please state if the data +# were corrected for the window effects. +# +# +# +# +# +# +# +# +# +# +# +# +# Were the recorded data corrected by the window effects of the +# focusing probes (lenses)? +# +# +# +# +# Specify the angular spread caused by the focusing probes. +# +# +# +# +# +# Properties of the rotating element defined in +# 'instrument/rotating_element_type'. +# +# +# +# Define which element rotates, e.g. polarizer or analyzer. +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Was the backside of the sample roughened? Relevant for infrared +# ellipsometry. +# +# +# +# +# +# Measured data, data errors, and varied parameters. This may be used to describe +# indirectly derived data or data transformed between different descriptions, +# such as: +# Raw Data --> Psi +# Delta Psi, Delta --> N,C,S +# Mueller matrix --> N,C,S +# Mueller matrix --> Psi, Delta +# etc. +# +# Other types of data, such as temperature or sample location, may be saved +# in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better +# directly in the location of the sample positioner or temperature sensor. +# +# +# +# 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). +# +# +# +# +# +# +# +# :ref:`External link <Design-Links>` to the data field in 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. +# +# Ideally, the link uses the relative path with respect to the actual +# NeXus file. +# +# +# +# +# +# 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. +# +# +# +# +# +# diff --git a/applications/nyaml/NXoptical_spectroscopy.yaml b/applications/nyaml/NXoptical_spectroscopy.yaml new file mode 100644 index 0000000000..81738ebb98 --- /dev/null +++ b/applications/nyaml/NXoptical_spectroscopy.yaml @@ -0,0 +1,1938 @@ +category: application +doc: | + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. + + For any free-text descriptions, it is recommended to use English, as this ensures + the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. +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_measurements: | + Number of measurements (1st dimension of measured data arrays). 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. + +# TODO: +# - Add NXoptical_lens and NXwaveplate to NXinstrument? +# - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. +# - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. +# - Add optical elements and rework them: NXfiber, NXbeam_splitter, +type: group +NXoptical_spectroscopy(NXobject): + (NXentry): + 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: [NXoptical_spectroscopy] + title: + exists: recommended + start_time(NX_DATE_TIME): + exists: recommended + doc: | + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise, the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + end_time(NX_DATE_TIME): + exists: recommended + doc: | + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + identifier_experiment: + exists: recommended + experiment_description: + exists: optional + doc: | + An optional free-text description of the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. + experiment_type: + doc: | + Specify the type of the optical experiment. + + Use another term if none of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. + enumeration: + open_enum: true + items: [photoluminescence, transmission spectroscopy, reflection spectroscopy] + experiment_sub_type: + exists: optional + doc: | + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. + enumeration: + open_enum: true + items: [time resolved, imaging, pump-probe] + beam_ref_frame(NXcoordinate_system): + exists: optional + depends_on(NX_CHAR): + doc: | + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. + (NXtransformations): + doc: | + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. + sample_normal_ref_frame(NXcoordinate_system): + exists: optional + depends_on(NX_CHAR): + doc: | + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. + (NXtransformations): + doc: | + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation + (NXinstrument): + doc: | + Devices or elements of the optical spectroscopy setup described with its + properties and general information. + + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties + beam_TYPE(NXbeam): + nameType: partial + exists: ['min', '1', 'max', 'unbounded'] + doc: | + This can be used to describe properties of a photon beam. + A beam can be connected to components, via their + "inputs" and "outputs". + + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are actually measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) + parameter_reliability: + doc: | + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). + enumeration: [measured, nominal] + incident_wavelength(NX_NUMBER): + exists: recommended + incident_wavelength_spread(NX_NUMBER): + exists: recommended + incident_polarization(NX_NUMBER): + exists: recommended + extent(NX_FLOAT): + exists: recommended + associated_source(NX_CHAR): + exists: optional + doc: | + The path to the device which emitted this beam (light source or frequency doubler). + + This parameter is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light source can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". + + Example: /entry/instrument/source_532nmlaser + beam_polarization_type: + exists: optional + enumeration: [linear, circular, elliptically, unpolarized] + linear_beam_sample_polarization(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. Note that the zero reference should be a direction vector for a + :ref:`reference_plane ` + normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. + This can be used if no definition of respective + coordinate systems for beam and sample normal is done. If coordinate systems + are defined, refer to beam "incident_polarization". + detector_TYPE(NXdetector): + nameType: partial + exists: ['min', '1', 'max', 'unbounded'] + detector_channel_type: + enumeration: [single-channel, multichannel] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: + open_enum: true + items: [CCD, photomultiplier, photodiode, avalanche-photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate] + raw_data(NXdata): + exists: recommended + doc: | + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + additional_detector_hardware: + exists: optional + doc: | + Specify respective hardware which was used for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). + device_information(NXfabrication): + exists: recommended + source_TYPE(NXsource): + nameType: partial + exists: recommended + type: + exists: recommended + enumeration: + open_enum: true + items: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Optical Laser, Laser, Dye-Laser, Broadband Tunable Light Source, Halogen lamp, LED, Mercury Cadmium Telluride, Deuterium Lamp, Xenon Lamp, Globar] + name: + exists: recommended + standard: + exists: optional + doc: | + If available, name/ID/norm of the light source standard. + device_information(NXfabrication): + exists: recommended + doc: | + Details about the device information. + associated_beam(NX_CHAR): + exists: recommended + doc: | + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" together with this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + (NXmonochromator): + exists: recommended + device_information(NXfabrication): + exists: recommended + angle_reference_frame: + exists: recommended + doc: | + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is possible as well: + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam + - angle of in-plane sample rotation (direction along the sample's surface normal) + enumeration: [beam centered, sample-normal centered] + omega(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between sample incident beam and sample surface. + twotheta(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between incident and detection beam + chi(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Sample tilt between sample normal, and the plane spanned by detection and + incident beam. + phi(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Inplane rotation of the sample, with rotation axis along sample normal. + angle_of_incidence(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. These two directions span the plane + of incidence. + angle_of_detection(NX_NUMBER): + exists: optional + unit: NX_ANGLE + 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. + These two directions span the plane of detection. + angle_of_incident_and_detection_beam(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + angle_of_in_plane_sample_rotation(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + generic_beam_sample_angle_TYPE(NXtransformations): + nameType: partial + exists: recommended + doc: | + Set of transformations, describing the relative orientation of different + parts of the experiment (beams or sample). You may select one of the specified + angles for incident and detection beam or sample, and then use polar and azimuthal + angles to define the direction via spherical coordinates. + This allows consistent definition between different coordinate system. + You may refer to self defined coordinate system as well. + + + If "angle_reference_frame = beam centered", then this coordinate system is used: + McStas system (NeXus default) + (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) + + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and + the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` + is vertically oriented. + + If "angle_reference_frame = sample-normal centered", then this coordinate + system is used + z - math:`[0,0,1]` along sample surface normal + x - math:`[1,0,0]` defined by sample surface projected incident beam. + y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. + For this case, x may be ill defined, if the incident beam is perpendicular + to the sample surface. In this case, use the beam centered description. + type: + enumeration: [incident beam, detection beam, sample] + polar(NX_NUMBER): + unit: NX_ANGLE + doc: | + Rotation about the y axis (polar rotation within the sample plane). + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 1, 0]] + \@depends_on: + doc: | + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. + azimuth(NX_NUMBER): + unit: NX_ANGLE + doc: | + Rotation about the z axis (azimuthal rotation within the sample plane). + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, 1]] + \@depends_on: + enumeration: [offset_tilt] + lateral_focal_point_offset(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + (NXcomponent): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Optical components along the optical beam path. + + Every object which interacts or modifies optical beam properties, + may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + (NXoptical_lens): + exists: optional + doc: | + This is the optical element used to focus or collect light. This may + be a generic lens or microcope objectives which are used for the + Raman scattering process. + type: + enumeration: + open_enum: true + items: [objective, lens, glass fiber, none] + device_information(NXfabrication): + exists: optional + (NXwaveplate): + exists: optional + (NXoptical_window): + exists: optional + polfilter_TYPE(NXcomponent): + exists: optional + nameType: partial + doc: | + Polarization filter to prepare light to be measured or to be incident + on the sample. + Generic polarization filter properties may be implemented via NXfilter_pol + at a later stage. + filter_mechanism(NX_CHAR): + exists: optional + doc: | + Physical principle of the polarization filter used to create a + defined incident or scattered light state. + enumeration: + open_enum: true + items: [polarization by Fresnel reflection, birefringent polarizers, thin film polarizers, wire-grid polarizers] + specific_polarization_filter_type(NX_CHAR): + exists: optional + doc: | + Specific name or type of the polarizer used. + + Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston + Polarizer... + device_information(NXfabrication): + exists: optional + spectralfilter_TYPE(NXcomponent): + exists: optional + nameType: partial + doc: | + Spectral filter used to modify properties of the scattered or incident light. + filter_type: + exists: optional + doc: | + Type of laser-line filter used to suppress the laser, if measurements + close to the laser-line are performed. + enumeration: + open_enum: true + long-pass filter: + doc: | + Blocks shorter wavelengths and transmits longer wavelengths. + short-pass filter: + doc: | + Blocks longer wavelengths and transmits shorter wavelengths. + notch filter: + doc: | + Blocks a narrow wavelength band while transmitting others. + reflection filter: + doc: | + Reflects certain wavelength ranges instead of absorbing them. + neutral density filter: + doc: | + Reduces light intensity uniformly across all wavelengths. + intended_use: + exists: optional + doc: | + Type of laser-line filter used to suppress the laser, if measurements + close to the laser-line are performed. + enumeration: + open_enum: true + items: [laser line cleanup, raylight line removal, spectral filtering, intensity manipulation] + filter_characteristics(NXdata): + exists: optional + doc: | + Properties of the spectral filter such as wavelength dependent transmission + or reflectivity. + \@characteristics_type: + exists: optional + doc: | + Which property is used to form the spectral properties of light, + i.e. transmission or reflection properties. + enumeration: [transmission, reflection] + device_information(NXfabrication): + exists: optional + (NXbeam_transfer_matrix_table): + exists: optional + doc: | + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. + sample_stage(NXmanipulator): + exists: optional + doc: | + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. + stage_type: + exists: optional + doc: | + Specify the type of the sample stage. + enumeration: + open_enum: true + items: [manual stage, scanning stage, liquid stage, gas cell, cryostat, heater] + transformations(NXtransformations): + exists: optional + doc: | + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. + beam_sample_relation: + exists: optional + doc: | + Description of relation of the beam with the sample. How does the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + This is redundant if a full orientation description is done via the + stage's "transformations" entry. + device_information(NXfabrication): + exists: optional + temperature_sensor(NXsensor): + exists: recommended + name: + exists: recommended + measurement: + enumeration: [temperature] + type: + exists: optional + value(NX_FLOAT): + device_information(NXfabrication): + exists: optional + temp_control_TYPE(NXactuator): + nameType: partial + exists: optional + doc: | + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + cooler_or_heater: + exists: recommended + enumeration: [cooler, heater] + type: + exists: optional + doc: | + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + (NXpid_controller): + exists: recommended + setpoint(NX_FLOAT): + exists: recommended + device_information(NXfabrication): + exists: optional + device_information(NXfabrication): + exists: recommended + doc: | + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + construction_year(NX_DATE_TIME): + exists: optional + software_TYPE(NXprogram): + nameType: partial + exists: recommended + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + \@version: + exists: recommended + 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: | + Description of the software by persistent resource, where the program, + code, script etc. can be found. + instrument_calibration_DEVICE(NXcalibration): + nameType: partial + exists: recommended + doc: | + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. + device_path: + exists: recommended + doc: | + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + calibration_accuracy(NXdata): + exists: optional + doc: | + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + calibration_status(NX_CHAR): + exists: recommended + doc: | + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + calibration_time. + enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] + calibration_time(NX_DATE_TIME): + exists: optional + doc: | + If calibration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + (NXdata): + exists: optional + doc: | + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. + wavelength_resolution(NXresolution): + exists: optional + doc: | + The overall resolution of the optical instrument. + physical_quantity: + enumeration: [wavelength] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Minimum distinguishable wavelength separation of peaks in spectra. + (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. + name: + sample_id: + exists: recommended + doc: | + Locally unique ID of the sample, used in the research institute or group. + physical_form: + exists: recommended + doc: | + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. + description: + exists: optional + doc: | + Free text description of the sample. + chemical_formula: + exists: recommended + 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: + 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'. + 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 timestamp when + the measured specimen surface was actively prepared. + history(NXhistory): + exists: recommended + doc: | + A set of activities that occurred to the sample prior to/during the experiment. + temperature_env(NXenvironment): + exists: recommended + doc: | + Sample temperature (either controlled or just measured). + temperature_nominal: + exists: optional + doc: | + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. + enumeration: + open_enum: true + items: [room temperature, liquid helium temperature, liquid nitrogen temperature] + temperature_sensor(NXsensor): + exists: recommended + doc: | + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + sample_heater(NXactuator): + exists: optional + doc: | + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + sample_cooler(NXactuator): + exists: optional + doc: | + Device for cooling the sample (Cryostat, Airflow cooler, etc.). + This should be a link to /entry/instrument/manipulator/cryostat. + (NXenvironment): + exists: optional + doc: | + Arbitrary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperature description of the sample. + sample_medium: + exists: recommended + doc: | + Medium, in which the sample is placed. + enumeration: + open_enum: true + items: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water] + sample_medium_refractive_indices(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + 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. + dimensions: + rank: 2 + dim: (2, N_spectrum) + thickness(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + 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. + thickness_determination: + exists: optional + doc: | + If a thickness if given, please specify how this thickness was estimated or + determined. + layer_structure: + exists: optional + 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. + sample_orientation: + exists: optional + doc: | + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. + substrate: + exists: recommended + doc: | + If the sample is grown or fixed on a substrate, specify this here by + a free text description. + (NXdata): + doc: | + Here generic types of data may be saved. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plottable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). + + You may provide multiple instances of NXdata + \@axes: + doc: | + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + \@signal: + doc: | + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) + measurement_data_calibration_TYPE(NXprocess): + nameType: partial + exists: recommended + wavelength_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + Calibrated wavelength axis. + derived_parameters(NXprocess): + exists: optional + doc: | + Parameters that are derived from the measured data. + depolarization(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Light loss due to depolarization as a value in [0-1]. + dimensions: + rank: 3 + dim: (N_measurements, 1, N_spectrum) + jones_quality_factor(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Jones quality factor. + dimensions: + rank: 3 + dim: (N_measurements, 1, N_spectrum) + reflectivity(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Reflectivity. + dimensions: + rank: 3 + dim: (N_measurements, 1, N_spectrum) + transmittance(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Transmittance. + dimensions: + rank: 3 + dim: (N_measurements, 1, N_spectrum) + ANALYSIS_program(NXprogram): + nameType: partial + 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: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2abaa11cec0a6ef98c266f2a2cf663d712ba684932dae831b3e2ad3d53ac1027 +# +# +# +# +# +# +# +# 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 measurements (1st dimension of measured data arrays). 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. +# +# +# +# +# A general application definition of optical spectroscopy elements, which may +# be used as a template to derive specialized optical spectroscopy experiments. +# +# Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, +# reflectivity/transmission spectroscopy. +# +# A general optical experiment consists of (i) a light/photon source, (ii) a sample, +# (iii) a detector. +# +# For any free-text descriptions, it is recommended to use English, as this ensures +# the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Datetime of the start of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise, the local time zone is assumed per ISO8601. +# +# It is required to enter at least one of both measurement times, either "start_time" or "end_time". +# +# +# +# +# Datetime of the end of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# It is required to enter at least one of both measurement times, either "start_time" or "end_time". +# +# +# +# +# +# An optional free-text description of the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into this field. +# +# The reason is that such a free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn how far the +# current base classes need extension based on user feedback. +# +# +# +# +# Specify the type of the optical experiment. +# +# Use another term if none of these methods are suitable. You may specify +# fundamental characteristics or properties in the experimental sub-type. +# +# For Raman spectroscopy or ellipsometry use the respective specializations +# of NXoptical_spectroscopy. +# +# +# +# +# +# +# +# +# +# Specify a special property or characteristic of the experiment, which specifies +# the generic experiment type. +# +# +# +# +# +# +# +# +# +# +# This refers to the coordinate system along the beam path. The origin and +# base is defined at z=0, where the incident beam hits the sample at the surface. +# +# +# +# +# This is the default NeXus coordinate system (McStas), if the transformation +# does not change the coordinate system at all - i.e. it is unity. +# Otherwise, by this a respective transformation of the beam +# reference frame to the default reference frame could be made. i.e. +# exchange of x and z coordinate, rotation of respective coordinates +# towards each other. +# +# +# +# +# +# +# Link to transformations defining the sample-normal base coordinate system, +# which is defined such that the positive z-axis is parallel to the sample normal, +# and the x-y-plane lies inside the sample surface. +# +# +# +# +# Set of transformations, describing the orientation of the sample-normal coordinate system +# with respect to the beam coordinate system (.). +# +# +# +# +# +# Contact information and eventually details of at persons who +# performed the measurements. This can be for example the principal +# investigator or student. Examples are: name, affiliation, address, telephone +# number, email, role as well as identifiers such as orcid or similar. +# It is recommended to add multiple users if relevant. +# +# Due to data privacy concerns, there is no minimum requirement. +# If no user with specific name is allowed to be given, it is required to +# assign at least an affiliation +# +# +# +# +# Devices or elements of the optical spectroscopy setup described with its +# properties and general information. +# +# This includes for example: +# - The beam device's or instrument's model, company, serial number, construction year, etc. +# - Used software or code +# - Experiment descriptive parameters as reference frames, resolution, calibration +# - Photon beams with their respective properties such as angles and polarization +# - Various optical beam path devices, which interact, manipulate or measure optical beams +# - Characteristics of the medium surrounding the sample +# - "Beam devices" for a beam path description +# - Stages(NXmanipulator) +# - Sensors and actuators to control or measure sample or beam properties +# +# +# +# This can be used to describe properties of a photon beam. +# A beam can be connected to components, via their +# "inputs" and "outputs". +# +# It is required to define at least one incident beam which is incident +# to the sample. You may specify if this beam parameters are actually measured +# or just nominal. +# If this beam is the output of a source, chose the same +# name appendix as for the NXsource instance (e.g. TYPE=532nm) +# +# +# +# Select the reliability of the respective beam characteristics. Either, +# the parameters are measured via another device or method or just given +# nominally via the properties of a light source properties (532nm, 100mW). +# +# +# +# +# +# +# +# +# +# +# +# +# The path to the device which emitted this beam (light source or frequency doubler). +# +# This parameter is recommended, if the previous optical element is a photon source. +# In this way, the properties of the laser or light source can be described +# and associated. +# The beam should be named with the same appendix as the source, e.g., +# for TYPE=532nmlaser, there should be both a NXsource named +# "source_532nmlaser" and a NXbeam named "beam_532nmlaser". +# +# Example: /entry/instrument/source_532nmlaser +# +# +# +# +# +# +# +# +# +# +# +# +# Angle of the linear polarized light, with respect to a fixed arbitrary +# defined 0° position. Note that the zero reference should be a direction vector for a +# :ref:`reference_plane </NXbeam/TRANSFORMATIONS/reference_plane-field>` +# normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. +# This can be used if no definition of respective +# coordinate systems for beam and sample normal is done. If coordinate systems +# are defined, refer to beam "incident_polarization". +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# Specify respective hardware which was used for the detector. For +# example special electronics required for time-correlated single photon +# counting (TCSPC). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If available, name/ID/norm of the light source standard. +# +# +# +# +# Details about the device information. +# +# +# +# +# The path to a beam emitted by this source. +# Should be named with the same appendix, e.g., +# for TYPE=532nmlaser, there should as well be +# a NXbeam named "beam_532nmlaser" together with this source +# instance named "source_532nmlaser" +# +# Example: /entry/instrument/beam_532nmlaser +# +# +# +# +# +# +# +# +# Defines the reference frame which is used to describe the sample orientation +# with respect to the beam directions. +# +# A beam centered description is the default and uses 4 angles(similar to XRD): +# - Omega (angle between sample surface and incident beam) +# - 2Theta (angle between the transmitted beam and the detection beam) +# - Chi (sample tilt angle, angle between plane#1 and the surface normal, +# plane#1 = spanned by incidence beam and detection +# and detection. If Chi=0°, then plane#1 is the plane of +# incidence in reflection setups) +# - Phi (inplane rotation of sample, rotation axis is the samples +# surface normal) +# +# +# A sample normal centered description is possible as well: +# - angle of incidence (angle between incident beam and sample surface) +# - angle of detection (angle between detection beam and sample surface) +# - angle of incident and detection beam +# - angle of in-plane sample rotation (direction along the sample's surface normal) +# +# +# +# +# +# +# +# +# Angle between sample incident beam and sample surface. +# +# +# +# +# Angle between incident and detection beam +# +# +# +# +# Sample tilt between sample normal, and the plane spanned by detection and +# incident beam. +# +# +# +# +# Inplane rotation of the sample, with rotation axis along sample normal. +# +# +# +# +# Angle(s) of the incident beam vs. the normal of the bottom reflective +# (substrate) surface in the sample. These two directions span the plane +# of incidence. +# +# +# +# +# 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. +# These two directions span the plane of detection. +# +# +# +# +# Angle between the incident and detection beam. +# If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, +# then the setup is a reflection setup. +# If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam +# then the setup may be a light scattering setup. +# (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but +# the angle source-sample-detector is 90°) +# +# +# +# +# Angle of the inplane orientation of the sample. This might be an arbitrary, +# angle without specific relation to the sample symmetry, +# of the angle to a specific sample property (i.e. crystallographic axis or sample +# shape such as wafer flat) +# +# +# +# +# Set of transformations, describing the relative orientation of different +# parts of the experiment (beams or sample). You may select one of the specified +# angles for incident and detection beam or sample, and then use polar and azimuthal +# angles to define the direction via spherical coordinates. +# This allows consistent definition between different coordinate system. +# You may refer to self defined coordinate system as well. +# +# +# If "angle_reference_frame = beam centered", then this coordinate system is used: +# McStas system (NeXus default) +# (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) +# +# i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and +# the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` +# is vertically oriented. +# +# If "angle_reference_frame = sample-normal centered", then this coordinate +# system is used +# z - math:`[0,0,1]` along sample surface normal +# x - math:`[1,0,0]` defined by sample surface projected incident beam. +# y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. +# For this case, x may be ill defined, if the incident beam is perpendicular +# to the sample surface. In this case, use the beam centered description. +# +# +# +# +# +# +# +# +# +# +# Rotation about the y axis (polar rotation within the sample plane). +# +# +# +# +# +# +# +# +# +# +# +# +# +# Path to a transformation that places the sample surface +# into the origin of the arpes_geometry coordinate system. +# +# +# +# +# +# Rotation about the z axis (azimuthal rotation within the sample plane). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if there is a lateral offset on the sample surface, between the focal +# points of the incident beam and the detection beam. +# +# +# +# +# Optical components along the optical beam path. +# +# Every object which interacts or modifies optical beam properties, +# may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, +# Detector, etc, +# +# +# +# +# This is the optical element used to focus or collect light. This may +# be a generic lens or microcope objectives which are used for the +# Raman scattering process. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Polarization filter to prepare light to be measured or to be incident +# on the sample. +# Generic polarization filter properties may be implemented via NXfilter_pol +# at a later stage. +# +# +# +# Physical principle of the polarization filter used to create a +# defined incident or scattered light state. +# +# +# +# +# +# +# +# +# +# +# Specific name or type of the polarizer used. +# +# Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston +# Polarizer... +# +# +# +# +# +# +# Spectral filter used to modify properties of the scattered or incident light. +# +# +# +# Type of laser-line filter used to suppress the laser, if measurements +# close to the laser-line are performed. +# +# +# +# Blocks shorter wavelengths and transmits longer wavelengths. +# +# +# Blocks longer wavelengths and transmits shorter wavelengths. +# +# +# Blocks a narrow wavelength band while transmitting others. +# +# +# Reflects certain wavelength ranges instead of absorbing them. +# +# +# Reduces light intensity uniformly across all wavelengths. +# +# +# +# +# +# Type of laser-line filter used to suppress the laser, if measurements +# close to the laser-line are performed. +# +# +# +# +# +# +# +# +# +# +# Properties of the spectral filter such as wavelength dependent transmission +# or reflectivity. +# +# +# +# Which property is used to form the spectral properties of light, +# i.e. transmission or reflection properties. +# +# +# +# +# +# +# +# +# +# +# +# Allows description of beam properties via matrices, which relate ingoing with +# outgoing beam properties. +# +# +# +# +# Sample stage (or manipulator) for positioning of the sample. This should +# only contain the spatial orientation of movement. +# +# +# +# Specify the type of the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# This allows a description of the stages relation or orientation and +# position with respect to the sample or beam, if an laboratory or +# an stage coordinate system is defined. +# +# +# +# +# Description of relation of the beam with the sample. How does the +# sample hit the beam, e.g. 'center of sample, long edge parallel +# to the plane of incidence'. +# This is redundant if a full orientation description is done via the +# stage's "transformations" entry. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of control for the sample temperature. Replace TYPE by "cryostat" or +# "heater" to specify it. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive +# +# +# +# +# +# +# +# +# +# General device information of the optical spectroscopy setup, if +# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). +# For custom build setups, this may be limited to the construction year. +# +# +# +# +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to control any parts of the optical spectroscopy setup. +# The uppercase TYPE should be replaced by a specification name, i.e. +# "software_detector" or "software_stage" to specify the respective +# program or software components. +# +# +# +# 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. +# +# +# +# +# Description of the software by persistent resource, where the program, +# code, script etc. can be found. +# +# +# +# +# +# +# Pre-calibration of an arbitrary device of the instrumental setup, which +# has the name DEVICE. You can specify here how, at which time by which method +# the calibration was done. As well the accuracy and a link to the calibration +# dataset. +# +# +# +# Path to the device, which was calibrated. +# Example: entry/instrument/DEVICE +# +# +# +# +# Provide data about the determined accuracy of the device, this may +# may be a single value or a dataset like wavelength error vs. wavelength etc. +# +# +# +# +# Was a calibration performed? If yes, when was it done? If the +# calibration time is provided, it should be specified in +# calibration_time. +# +# +# +# +# +# +# +# +# +# +# +# If calibration status is 'calibration time provided', specify the +# ISO8601 date when calibration was last performed before this +# measurement. UTC offset should be specified. +# +# +# +# +# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. +# This can be for example the instrument response function. +# +# +# +# +# +# The overall resolution of the optical instrument. +# +# +# +# +# +# +# +# +# +# Minimum distinguishable wavelength separation of peaks in spectra. +# +# +# +# +# +# +# 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. +# +# +# +# +# Locally unique ID of the sample, used in the research institute or group. +# +# +# +# +# State the form of the sample, examples are: +# thin film, single crystal, poly crystal, amorphous, single layer, +# multi layer, liquid, gas, pellet, powder. +# Generic properties of liquids or gases see NXsample properties. +# +# +# +# +# Free text description of the sample. +# +# +# +# +# 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'. +# +# +# +# +# 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 timestamp when +# the measured specimen surface was actively prepared. +# +# +# +# +# A set of activities that occurred to the sample prior to/during the experiment. +# +# +# +# +# Sample temperature (either controlled or just measured). +# +# +# +# If no sensor was available for the determination of temperature, selected +# a nominal value which represents approximately the situation of sample temperature. +# +# +# +# +# +# +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# Device for cooling the sample (Cryostat, Airflow cooler, etc.). +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# +# +# +# +# Arbitrary sample property which may be varied during the experiment +# and controlled by a device. Examples are pressure, voltage, magnetic field etc. +# Similar to the temperature description of the sample. +# +# +# +# Medium, in which the sample is placed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# (Measured) sample thickness. +# +# The information is recorded to qualify if the light used was likely +# able to shine through the sample. +# +# 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. +# +# +# +# +# If a thickness if given, please specify how this thickness was estimated or +# determined. +# +# +# +# +# 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. +# +# +# +# +# Specify the sample orientation, how is its sample normal oriented +# relative in the laboratory reference frame, incident beam reference +# frame. +# +# +# +# +# If the sample is grown or fixed on a substrate, specify this here by +# a free text description. +# +# +# +# +# +# Here generic types of data may be saved. This may refer to data derived +# from single or multiple raw measurements (i.e. several intensities are +# evaluated for different parameters: ellipsometry -> psi and delta) - +# i.e. non-raw data. +# As well plottable data may be stored/linked here, which provides the most suitable +# representation of the data (for the respective community). +# +# You may provide multiple instances of NXdata +# +# +# +# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) +# +# +# +# +# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) +# +# +# +# +# +# +# +# Calibrated wavelength axis. +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXraman.yaml b/applications/nyaml/NXraman.yaml new file mode 100644 index 0000000000..21a6155039 --- /dev/null +++ b/applications/nyaml/NXraman.yaml @@ -0,0 +1,351 @@ +category: application +doc: | + An application definition for Raman spectroscopy experiments. + + This application definition supports a wide range of Raman spectroscopy experiments. + These may be as simple as acquiring a single Raman spectrum from spontaneous Raman + scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also + includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant + Raman scattering, and multidimensional Raman spectra collected under varying conditions + such as temperature, pressure, or electric field. + + The application definition comprises two main components: + + 1. Structures defined in NXoptical_spectroscopy: + * Instrument configuration and data calibration + * Sensors monitoring sample or beam conditions + + 2. Structures specified and extended in NXraman: + * Description of the experiment type + * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) + * Detailed description of beam properties and their interaction with the sample + * Sample-specific information + + Information on Raman spectroscopy are provided in: + + General + + * Lewis, Ian R.; Edwards, Howell G. M. + Handbook of Raman Spectroscopy + ISBN 0-8247-0557-2 + + Raman scattering selection rules + + * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. + Group Theory - Application to the Physics ofCondensed Matter + ISBN 3540328971 + + Semiconductors + + * Manuel Cardona + Light Scattering in Solids I + eBook ISBN: 978-3-540-37568-5 + DOI: https://doi.org/10.1007/978-3-540-37568-5 + + * Manuel Cardona, Gernot Güntherodt + Light Scattering in Solids II + eBook ISBN: 978-3-540-39075-6 + DOI: https://doi.org/10.1007/3-540-11380-0 + + * See as well other Books from the "Light Scattering in Solids" series: + III: Recent Results + IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects + V: Superlattices and Other Microstructures + VI: Recent Results, Including High-Tc Superconductivity + VII: Crystal-Field and Magnetic Excitations + VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons + IX: Novel Materials and Techniques + + Glasses, Liquids, Gasses, ... + + Review articles: + Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, + Surface-enhanced Raman scattering, Tip-enhanced Raman scattering + * https://doi.org/10.1186/s11671-019-3039-2 +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_scattering_configurations: | + Number of scattering configurations used in the measurement. + It is 1 for only parallel polarization measurement, 2 for parallel and cross + polarization measurement or larger, if i.e. the incident and scattered photon + direction is varied. +type: group +NXraman(NXoptical_spectroscopy): + (NXentry): + definition: + doc: | + An application definition for Raman spectroscopy. + \@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: [NXraman] + title: + exists: recommended + experiment_type: + doc: | + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + enumeration: [Raman spectroscopy] + raman_experiment_type: + doc: | + Specify the type of Raman experiment. + enumeration: + open_enum: true + items: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, tip-enhanced Raman spectroscopy (TERS), surface-enhanced Raman spectroscopy (SERS), surface plasmon polariton enhanced Raman scattering (SPPERS), hyper Raman spectroscopy (HRS), stimulated Raman spectroscopy (SRS), inverse Raman spectroscopy (IRS), coherent anti-Stokes Raman spectroscopy (CARS)] + (NXinstrument): + doc: | + Metadata of the setup, its optical elements and physical properties which + defines the Raman measurement. + scattering_configuration(NX_CHAR): + doc: | + Scattering configuration as defined by the porto notation by three + states, which are orthogonal to each other. Example: z(xx)z for + parallel polarized backscattering configuration. + + See: + https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman + + A(BC)D + + A = The propagation direction of the incident light (k_i) + B = The polarization direction of the incident light (E_i) + C = The polarization direction of the scattered light (E_s) + D = The propagation direction of the scattered light (k_s) + + An orthogonal base is assumed. + Linear polarized light is displayed by e.g. "x","y" or "z" + Unpolarized light is displayed by "." + For non-orthogonal vectors, use the attribute porto_notation_vectors. + \@porto_notation_vectors(NX_NUMBER): + exists: recommended + doc: | + Scattering configuration as defined by the porto notation given by + respective vectors. + + Vectors in the porto notation are defined as for A, B, C, D above. + Linear light polarization is assumed. + dimensions: + rank: 3 + doc: | + 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. + A has to be perpendicular to B and C perpendicular to D. + dim: (4, 3, N_scattering_configurations) + beam_incident(NXbeam): + doc: | + Beam which is incident to the sample. + wavelength(NX_NUMBER): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c5d06c501a185d18e65f69e222da31d55588a20c9ebf765f9059307068212045 +# +# +# +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# Number of scattering configurations used in the measurement. +# It is 1 for only parallel polarization measurement, 2 for parallel and cross +# polarization measurement or larger, if i.e. the incident and scattered photon +# direction is varied. +# +# +# +# +# An application definition for Raman spectroscopy experiments. +# +# This application definition supports a wide range of Raman spectroscopy experiments. +# These may be as simple as acquiring a single Raman spectrum from spontaneous Raman +# scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also +# includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant +# Raman scattering, and multidimensional Raman spectra collected under varying conditions +# such as temperature, pressure, or electric field. +# +# The application definition comprises two main components: +# +# 1. Structures defined in NXoptical_spectroscopy: +# * Instrument configuration and data calibration +# * Sensors monitoring sample or beam conditions +# +# 2. Structures specified and extended in NXraman: +# * Description of the experiment type +# * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) +# * Detailed description of beam properties and their interaction with the sample +# * Sample-specific information +# +# Information on Raman spectroscopy are provided in: +# +# General +# +# * Lewis, Ian R.; Edwards, Howell G. M. +# Handbook of Raman Spectroscopy +# ISBN 0-8247-0557-2 +# +# Raman scattering selection rules +# +# * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. +# Group Theory - Application to the Physics ofCondensed Matter +# ISBN 3540328971 +# +# Semiconductors +# +# * Manuel Cardona +# Light Scattering in Solids I +# eBook ISBN: 978-3-540-37568-5 +# DOI: https://doi.org/10.1007/978-3-540-37568-5 +# +# * Manuel Cardona, Gernot Güntherodt +# Light Scattering in Solids II +# eBook ISBN: 978-3-540-39075-6 +# DOI: https://doi.org/10.1007/3-540-11380-0 +# +# * See as well other Books from the "Light Scattering in Solids" series: +# III: Recent Results +# IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects +# V: Superlattices and Other Microstructures +# VI: Recent Results, Including High-Tc Superconductivity +# VII: Crystal-Field and Magnetic Excitations +# VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons +# IX: Novel Materials and Techniques +# +# Glasses, Liquids, Gasses, ... +# +# Review articles: +# Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, +# Surface-enhanced Raman scattering, Tip-enhanced Raman scattering +# * https://doi.org/10.1186/s11671-019-3039-2 +# +# +# +# +# An application definition for Raman spectroscopy. +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Specify the type of the optical experiment. +# +# You may specify fundamental characteristics or properties in the experimental sub-type. +# +# +# +# +# +# +# +# Specify the type of Raman experiment. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Metadata of the setup, its optical elements and physical properties which +# defines the Raman measurement. +# +# +# +# Scattering configuration as defined by the porto notation by three +# states, which are orthogonal to each other. Example: z(xx)z for +# parallel polarized backscattering configuration. +# +# See: +# https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman +# +# A(BC)D +# +# A = The propagation direction of the incident light (k_i) +# B = The polarization direction of the incident light (E_i) +# C = The polarization direction of the scattered light (E_s) +# D = The propagation direction of the scattered light (k_s) +# +# An orthogonal base is assumed. +# Linear polarized light is displayed by e.g. "x","y" or "z" +# Unpolarized light is displayed by "." +# For non-orthogonal vectors, use the attribute porto_notation_vectors. +# +# +# +# Scattering configuration as defined by the porto notation given by +# respective vectors. +# +# Vectors in the porto notation are defined as for A, B, C, D above. +# Linear light polarization is assumed. +# +# +# +# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. +# A has to be perpendicular to B and C perpendicular to D. +# +# +# +# +# +# +# +# +# +# Beam which is incident to the sample. +# +# +# +# +# +# diff --git a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml new file mode 100644 index 0000000000..c094a91989 --- /dev/null +++ b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml @@ -0,0 +1,117 @@ + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the array associated to the data type. + + + + + Contains data structures of an experimental optical setup (i.e., multiple + transfer matrix tables). These data structures are used to relate physical + properties of two beams (NXbeam) which have one common optical component + (NXcomponent) (one specific transfer matrix). + One of these beams is an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. + + + + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + + + + + + + + + + + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + + + + + + + + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfer matrix relationship between N input beams and M output beams. + It contains a table with the relevant matrices to be used for different + transmitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of a beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfer matrix table has the dimension NxM. + + For each entry, in this transfer matrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfer matrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + + + + + + + + Specific name of input beam which the transfer matrix table is related to. + + + + + Specific name of output beam which the transfer matrix table is related to. + + + + diff --git a/base_classes/NXoptical_lens.nxdl.xml b/base_classes/NXoptical_lens.nxdl.xml new file mode 100644 index 0000000000..084e5fc4ca --- /dev/null +++ b/base_classes/NXoptical_lens.nxdl.xml @@ -0,0 +1,185 @@ + + + + + + + + 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. + + + + Type of the lens (e.g. concave, convex etc.). + + + + + + + + + + + + + + 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_radius_front or curvature_radius_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. + + + + + The numerical aperture of the lens. + + + + + Magnification of the lens + + + diff --git a/base_classes/NXoptical_window.nxdl.xml b/base_classes/NXoptical_window.nxdl.xml new file mode 100644 index 0000000000..93ed238397 --- /dev/null +++ b/base_classes/NXoptical_window.nxdl.xml @@ -0,0 +1,126 @@ + + + + + + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + + This describes cryostat windows and other possible influences for ellipsometry + measurements. + + 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). + + 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 measurements should be + considered as a separate experiment (with a separate NeXus file), and + the reference data shall be :ref:`linked <Design-Links>` in + ``reference_data_link``. + + 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. + + + + Was a window correction performed? If so, describe the window + correction procedure in ``window_correction/procedure``. + + + + + Type of effects due to this window on the measurement. + + + + + + + + + + + Group to describe any window correction - if none performed, then omit this + + + + 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_file``. + + + + + :ref:`External link <Design-Links>` to the data field in the NeXus file which describes + the reference data if a reference measurement for window correction + was performed. + + Ideally, the reference measurement was performed on the same sample, + using the same conditions as for the actual measurement, with + and, if possible, without windows. It should have been conducted as close in time + to the actual measurement as possible. + + Ideally, the link uses the relative path with respect to the actual + NeXus file. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, describe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + diff --git a/base_classes/NXwaveplate.nxdl.xml b/base_classes/NXwaveplate.nxdl.xml new file mode 100644 index 0000000000..2fd59f6fbd --- /dev/null +++ b/base_classes/NXwaveplate.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + + 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 or zero-order). + + + + + + + + + + + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4)). + + + + + + + + + + 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). In this case, also use type="achromatic". + + + + + + + + Wavelength resolved retardance of the waveplate. + + + + + Diameter of the waveplate (if the waveplate is circular). + + + + + 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 waveplate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + + + + Specify the material of the waveplate. If the device has a + coating it should be described in coating/coating_material. + + + + + Thickness of the waveplate substrate. + + + + + Complex index of refraction of the waveplate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. + + + + + + + + + + Is the waveplate 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. + + + diff --git a/base_classes/nyaml/NXbeam_transfer_matrix_table.yaml b/base_classes/nyaml/NXbeam_transfer_matrix_table.yaml new file mode 100644 index 0000000000..ad1b83f2b2 --- /dev/null +++ b/base_classes/nyaml/NXbeam_transfer_matrix_table.yaml @@ -0,0 +1,195 @@ +category: base +doc: | + Contains data structures of an experimental optical setup (i.e., multiple + transfer matrix tables). These data structures are used to relate physical + properties of two beams (NXbeam) which have one common optical component + (NXcomponent) (one specific transfer matrix). + One of these beams is an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_variables: | + Length of the array associated to the data type. +type: group +NXbeam_transfer_matrix_table(NXobject): + datatype_N: + nameType: partial + doc: | + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + enumeration: [aperture, focal length, orientation, jones matrix] + matrix_elements: + doc: | + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + dimensions: + rank: 1 + dim: (N_variables,) + TRANSFER_MATRIX(NX_NUMBER): + nameType: any + doc: | + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfer matrix relationship between N input beams and M output beams. + It contains a table with the relevant matrices to be used for different + transmitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of a beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfer matrix table has the dimension NxM. + + For each entry, in this transfer matrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfer matrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + dimensions: + rank: 2 + dim: (N_variables, N_variables) + \@input: + doc: | + Specific name of input beam which the transfer matrix table is related to. + \@output: + doc: | + Specific name of output beam which the transfer matrix table is related to. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e900939e0c3c854484795c7abc0217a49b21dc801fe96f5245be2f36633ce3cd +# +# +# +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# Length of the array associated to the data type. +# +# +# +# +# Contains data structures of an experimental optical setup (i.e., multiple +# transfer matrix tables). These data structures are used to relate physical +# properties of two beams (NXbeam) which have one common optical component +# (NXcomponent) (one specific transfer matrix). +# One of these beams is an input beam and the other one is an output beam. +# +# The data describes the change of beam properties, e.g. the intensity of a +# beam is reduced because the transmission coefficient of the beam device is +# lower than 1. +# +# +# +# Select which type of data was recorded, for example aperture and +# focal length. +# It is possible to have multiple selections. This selection defines +# how many columns (N_variables) are stored in the data array. +# N in the name, is the index number in which order the given +# property is listed. +# +# +# +# +# +# +# +# +# +# +# Please list in this array the column and row names used in your actual data. +# That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] +# and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix +# ['JM1','JM2'] +# +# +# +# +# +# +# +# Contains the datastructure which relates beam properties of an +# input and output beam as result of the input beam interaction +# with the beam device. +# +# Transfer matrix relationship between N input beams and M output beams. +# It contains a table with the relevant matrices to be used for different +# transmitted properties (such as polarization, intensity, phase). +# +# Data structure for all transfermatrices of a beam device in a setup. +# For each combination of N input and M output beams and for L physical +# concept (i.e. beam intensity), one matrix can be defined. +# +# In this way, the transfer matrix table has the dimension NxM. +# +# For each entry, in this transfer matrix, there are L formalisms. +# Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, +# whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). +# +# A beamsplitter with two input laser beams can have a total of +# four transfermatrices (2 Input x 2 Output). +# +# The dimension of the transfer matrix depends on the parameters. +# Examples are: +# 1x1 for intensity/power +# 2x2 for jones formalism +# 3x3 for direction +# +# +# +# +# +# +# +# Specific name of input beam which the transfer matrix table is related to. +# +# +# +# +# Specific name of output beam which the transfer matrix table is related to. +# +# +# +# diff --git a/base_classes/nyaml/NXoptical_lens.yaml b/base_classes/nyaml/NXoptical_lens.yaml new file mode 100644 index 0000000000..b6f7d986c5 --- /dev/null +++ b/base_classes/nyaml/NXoptical_lens.yaml @@ -0,0 +1,309 @@ +category: base +doc: | + Description of an optical lens. +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. +type: group +NXoptical_lens(NXcomponent): + type: + doc: | + Type of the lens (e.g. concave, convex etc.). + enumeration: + open_enum: true + items: [biconcave, plano-concave, convexo-concave, biconvex, plano-convex, concavo-convex, Fresnel lens] + chromatic(NX_BOOLEAN): + doc: | + Is it a chromatic lens? + lens_diameter(NX_NUMBER): + unit: NX_LENGTH + doc: | + Diameter of the lens. + 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): + unit: NX_LENGTH + doc: | + Thickness of the lens substrate at the optical axis. + index_of_refraction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the lens material. Specify at given + wavelength (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: (2, N_spectrum) + COATING(NXsample): + nameType: any + 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): + unit: NX_LENGTH + doc: | + Thickness of the coating. + index_of_refraction_coating(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: (2, N_spectrum_coating) + reflectance: + unit: NX_UNITLESS + doc: | + Reflectance of the lens at given spectral values. + dimensions: + rank: 1 + dim: (N_spectrum_RT,) + transmission: + unit: NX_UNITLESS + doc: | + Transmission of the lens at given spectral values. + dimensions: + rank: 1 + dim: (N_spectrum_RT,) + focal_length(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + 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). + dimensions: + rank: 1 + dim: (2,) + curvature_radius_FACE(NX_NUMBER): + nameType: partial + exists: recommended + unit: NX_LENGTH + 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_radius_front or curvature_radius_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(NX_NUMBER): + nameType: specified + unit: NX_UNITLESS + doc: | + Abbe number (or V-number) of the lens. + numerical_aperture(NX_NUMBER): + doc: | + The numerical aperture of the lens. + magnification(NX_FLOAT): + doc: | + Magnification of the lens + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ff3aacdecbd2c9293ac333fafe4799f9a696484027f8b97362b534b39fcea2de +# +# +# +# +# +# +# +# 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. +# +# +# +# Type of the lens (e.g. concave, convex etc.). +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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_radius_front or curvature_radius_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. +# +# +# +# +# The numerical aperture of the lens. +# +# +# +# +# Magnification of the lens +# +# +# diff --git a/base_classes/nyaml/NXoptical_window.yaml b/base_classes/nyaml/NXoptical_window.yaml new file mode 100644 index 0000000000..e862701bb3 --- /dev/null +++ b/base_classes/nyaml/NXoptical_window.yaml @@ -0,0 +1,206 @@ +category: base +doc: | + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + + This describes cryostat windows and other possible influences for ellipsometry + measurements. + + 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). + + 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 measurements should be + considered as a separate experiment (with a separate NeXus file), and + the reference data shall be :ref:`linked ` in + ``reference_data_link``. + + 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. +type: group +NXoptical_window(NXaperture): + window_effects_corrected(NX_BOOLEAN): + doc: | + Was a window correction performed? If so, describe the window + correction procedure in ``window_correction/procedure``. + window_effects_type: + doc: | + Type of effects due to this window on the measurement. + enumeration: + open_enum: true + items: [interference effects, light absorption, light scattering, other] + window_correction(NXprocess): + doc: | + Group to describe any window correction - if none performed, then omit this + 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_file``. + reference_data_link(NX_NUMBER): + doc: | + :ref:`External link ` to the data field in the NeXus file which describes + the reference data if a reference measurement for window correction + was performed. + + Ideally, the reference measurement was performed on the same sample, + using the same conditions as for the actual measurement, with + and, if possible, without windows. It should have been conducted as close in time + to the actual measurement as possible. + + Ideally, the link uses the relative path with respect to the actual + NeXus file. + material(NX_CHAR): + doc: | + The material of the window. + enumeration: + open_enum: true + items: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] + material_other(NX_CHAR): + doc: | + If you specified 'other' as material, describe here what it is. + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the window. + orientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5fbdbc3ec2cf46c2adbe2c08207711d9584d29cc74618e7783dfc8eb358b34f1 +# +# +# +# +# +# A window of a cryostat, heater, vacuum chamber or a simple glass slide. +# +# This describes cryostat windows and other possible influences for ellipsometry +# measurements. +# +# 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). +# +# 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 measurements should be +# considered as a separate experiment (with a separate NeXus file), and +# the reference data shall be :ref:`linked <Design-Links>` in +# ``reference_data_link``. +# +# 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. +# +# +# +# Was a window correction performed? If so, describe the window +# correction procedure in ``window_correction/procedure``. +# +# +# +# +# Type of effects due to this window on the measurement. +# +# +# +# +# +# +# +# +# +# +# Group to describe any window correction - if none performed, then omit this +# +# +# +# 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_file``. +# +# +# +# +# :ref:`External link <Design-Links>` to the data field in the NeXus file which describes +# the reference data if a reference measurement for window correction +# was performed. +# +# Ideally, the reference measurement was performed on the same sample, +# using the same conditions as for the actual measurement, with +# and, if possible, without windows. It should have been conducted as close in time +# to the actual measurement as possible. +# +# Ideally, the link uses the relative path with respect to the actual +# NeXus file. +# +# +# +# +# +# The material of the window. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you specified 'other' as material, describe here what it is. +# +# +# +# +# Thickness of the window. +# +# +# +# +# Angle of the window normal (outer) vs. the substrate normal +# (similar to the angle of incidence). +# +# +# diff --git a/base_classes/nyaml/NXwaveplate.yaml b/base_classes/nyaml/NXwaveplate.yaml new file mode 100644 index 0000000000..e7d2337481 --- /dev/null +++ b/base_classes/nyaml/NXwaveplate.yaml @@ -0,0 +1,276 @@ +category: base +doc: | + A waveplate or retarder. +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. +type: group +NXwaveplate(NXcomponent): + type: + doc: | + Type of waveplate (e.g. achromatic or zero-order). + enumeration: + open_enum: true + items: [zero-order, achromatic, multiple-order, dual-wavelength] + retardance: + doc: | + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4)). + enumeration: [full-wave, half-wave, quarter-wave] + 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). In this case, also use type="achromatic". + dimensions: + rank: 1 + dim: (N_wavelengths,) + retardance_distribution(NXdata): + doc: | + Wavelength resolved retardance of the waveplate. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the waveplate (if the waveplate is circular). + clear_aperture(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of + length/height for square geometry). + + # Would it be better to provide the clear aperture as length? + substrate(NXsample): + doc: | + Describe the material of the substrate of the waveplate 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 waveplate. If the device has a + coating it should be described in coating/coating_material. + substrate_thickness(NX_NUMBER): + unit: NX_LENGTH + doc: | + Thickness of the waveplate substrate. + index_of_refraction_substrate(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the waveplate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: (2, N_spectrum) + coating(NXsample): + doc: | + Is the waveplate 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): + unit: NX_LENGTH + doc: | + Thickness of the coating. + 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: (2,) + index_of_refraction_coating(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: (2, N_spectrum) + reflectance(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Average reflectance of the waveplate in percentage. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fa0e24f757f671085313b91e45bbdd4b7ae6ecf448e4f5166c33a121a9fc9288 +# +# +# +# +# +# +# +# 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 or zero-order). +# +# +# +# +# +# +# +# +# +# +# Specify the retardance of the waveplate (e.g. full-wave, half-wave +# (lambda/2), quarter-wave (lambda/4)). +# +# +# +# +# +# +# +# +# +# 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). In this case, also use type="achromatic". +# +# +# +# +# +# +# +# Wavelength resolved retardance of the waveplate. +# +# +# +# +# Diameter of the waveplate (if the waveplate is circular). +# +# +# +# +# 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 waveplate in +# substrate/substrate_material and provide its index of refraction in +# substrate/index_of_refraction_substrate, if known. +# +# +# +# Specify the material of the waveplate. If the device has a +# coating it should be described in coating/coating_material. +# +# +# +# +# Thickness of the waveplate substrate. +# +# +# +# +# Complex index of refraction of the waveplate substrate. Specify at +# given wavelength (or energy, wavenumber etc.) values. +# +# +# +# +# +# +# +# +# +# Is the waveplate 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 6f5a32a6417bfb0fb6afb1e9d7139ad1aed04192 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 15 Jul 2025 22:27:40 +0200 Subject: [PATCH 41/57] Given that mpes, xps, apm and opt were standardized, and em, and cg in ancestor commits to this commit added either as they were accepted from the NIAC main or as they are speculatively assumed - to not further block modifications to the software tools - there are no remaining appdef changes that might still need some old FAIRamt contributed definitions. Therefore, this commit removes all yaml and nxdl files from all those classes that are no longer developed that have been promoted already to the base classes or appdefs or some classes which are no longer developed further, reasons were: i) removed because obsolete: NXion,roi,sample_component_set, ii) removed postpone for future: NXlab_electro...,lab_sample..., microstructure_gragles_..., microstructure_imm..., iii) remove promoted to appdef NXapm,ellipsometry,em,optical_spectroscopy,raman, iv) remove because promoted to base class, remaining of the removed --- applications/NXem.nxdl.xml | 6 +- applications/nyaml/NXem.yaml | 11 +- base_classes/NXinstrument_em.nxdl.xml | 4 +- base_classes/nyaml/NXinstrument_em.yaml | 8 +- contributed_definitions/NXaberration.nxdl.xml | 76 - contributed_definitions/NXapm.nxdl.xml | 1309 ------- .../NXapm_charge_state_analysis.nxdl.xml | 168 - .../NXapm_measurement.nxdl.xml | 30 - .../NXapm_ranging.nxdl.xml | 111 - .../NXapm_reconstruction.nxdl.xml | 217 -- .../NXapm_simulation.nxdl.xml | 33 - contributed_definitions/NXatom.nxdl.xml | 147 - .../NXbeam_transfer_matrix_table.nxdl.xml | 117 - .../NXcg_alpha_complex.nxdl.xml | 101 - .../NXcg_cylinder.nxdl.xml | 133 - .../NXcg_ellipsoid.nxdl.xml | 81 - .../NXcg_face_list_data_structure.nxdl.xml | 227 -- contributed_definitions/NXcg_grid.nxdl.xml | 178 - .../NXcg_half_edge_data_structure.nxdl.xml | 195 - .../NXcg_hexahedron.nxdl.xml | 191 - .../NXcg_parallelogram.nxdl.xml | 101 - contributed_definitions/NXcg_point.nxdl.xml | 87 - contributed_definitions/NXcg_polygon.nxdl.xml | 126 - .../NXcg_polyhedron.nxdl.xml | 114 - .../NXcg_polyline.nxdl.xml | 140 - .../NXcg_primitive.nxdl.xml | 247 -- contributed_definitions/NXcg_roi.nxdl.xml | 49 - .../NXcg_tetrahedron.nxdl.xml | 76 - .../NXcg_triangle.nxdl.xml | 92 - .../NXcg_unit_normal.nxdl.xml | 75 - .../NXchemical_composition.nxdl.xml | 91 - contributed_definitions/NXcircuit.nxdl.xml | 163 - .../NXcorrector_cs.nxdl.xml | 169 - .../NXcs_computer.nxdl.xml | 57 - .../NXcs_filter_boolean_mask.nxdl.xml | 114 - contributed_definitions/NXcs_memory.nxdl.xml | 44 - contributed_definitions/NXcs_prng.nxdl.xml | 83 - contributed_definitions/NXcs_process.nxdl.xml | 52 - .../NXcs_profiling.nxdl.xml | 149 - .../NXcs_profiling_event.nxdl.xml | 98 - contributed_definitions/NXcs_storage.nxdl.xml | 45 - .../NXebeam_column.nxdl.xml | 238 -- .../NXellipsometry.nxdl.xml | 405 --- contributed_definitions/NXem.nxdl.xml | 1613 --------- contributed_definitions/NXem_ebsd.nxdl.xml | 678 ---- contributed_definitions/NXem_eds.nxdl.xml | 200 -- contributed_definitions/NXem_eels.nxdl.xml | 58 - contributed_definitions/NXem_img.nxdl.xml | 62 - .../NXem_measurement.nxdl.xml | 30 - .../NXem_simulation.nxdl.xml | 32 - .../NXevent_data_apm.nxdl.xml | 170 - .../NXevent_data_em.nxdl.xml | 157 - .../NXibeam_column.nxdl.xml | 136 - contributed_definitions/NXimage.nxdl.xml | 627 ---- .../NXinstrument_apm.nxdl.xml | 392 -- .../NXinstrument_em.nxdl.xml | 227 -- .../NXinteraction_volume_em.nxdl.xml | 56 - contributed_definitions/NXion.nxdl.xml | 112 - ...ctro_chemo_mechanical_preparation.nxdl.xml | 183 - .../NXlab_sample_mounting.nxdl.xml | 93 - .../NXmicrostructure_gragles_config.nxdl.xml | 369 -- .../NXmicrostructure_gragles_results.nxdl.xml | 293 -- .../NXmicrostructure_imm_config.nxdl.xml | 242 -- .../NXmicrostructure_imm_results.nxdl.xml | 189 - .../NXoptical_lens.nxdl.xml | 185 - .../NXoptical_spectroscopy.nxdl.xml | 1087 ------ .../NXoptical_system_em.nxdl.xml | 159 - .../NXoptical_window.nxdl.xml | 126 - contributed_definitions/NXphase.nxdl.xml | 76 - contributed_definitions/NXprogram.nxdl.xml | 47 - contributed_definitions/NXpump.nxdl.xml | 42 - contributed_definitions/NXraman.nxdl.xml | 229 -- contributed_definitions/NXroi.nxdl.xml | 40 - contributed_definitions/NXrotations.nxdl.xml | 244 -- .../NXsample_component_set.nxdl.xml | 78 - contributed_definitions/NXscanbox_em.nxdl.xml | 80 - contributed_definitions/NXspectrum.nxdl.xml | 550 --- contributed_definitions/NXunit_cell.nxdl.xml | 164 - contributed_definitions/NXwaveplate.nxdl.xml | 168 - .../nyaml/NXaberration.yaml | 122 - contributed_definitions/nyaml/NXapm.yaml | 2511 ------------- .../nyaml/NXapm_charge_state_analysis.yaml | 295 -- .../nyaml/NXapm_measurement.yaml | 40 - .../nyaml/NXapm_ranging.yaml | 188 - .../nyaml/NXapm_reconstruction.yaml | 377 -- .../nyaml/NXapm_simulation.yaml | 46 - contributed_definitions/nyaml/NXatom.yaml | 249 -- .../nyaml/NXbeam_transfer_matrix_table.yaml | 195 - .../nyaml/NXcg_alpha_complex.yaml | 166 - .../nyaml/NXcg_cylinder.yaml | 229 -- .../nyaml/NXcg_ellipsoid.yaml | 131 - .../nyaml/NXcg_face_list_data_structure.yaml | 397 -- contributed_definitions/nyaml/NXcg_grid.yaml | 308 -- .../nyaml/NXcg_half_edge_data_structure.yaml | 341 -- .../nyaml/NXcg_hexahedron.yaml | 342 -- .../nyaml/NXcg_parallelogram.yaml | 172 - contributed_definitions/nyaml/NXcg_point.yaml | 139 - .../nyaml/NXcg_polygon.yaml | 217 -- .../nyaml/NXcg_polyhedron.yaml | 190 - .../nyaml/NXcg_polyline.yaml | 238 -- .../nyaml/NXcg_primitive.yaml | 432 --- contributed_definitions/nyaml/NXcg_roi.yaml | 77 - .../nyaml/NXcg_tetrahedron.yaml | 120 - .../nyaml/NXcg_triangle.yaml | 145 - .../nyaml/NXcg_unit_normal.yaml | 120 - .../nyaml/NXchemical_composition.yaml | 149 - contributed_definitions/nyaml/NXcircuit.yaml | 272 -- .../nyaml/NXcorrector_cs.yaml | 303 -- .../nyaml/NXcs_computer.yaml | 87 - .../nyaml/NXcs_filter_boolean_mask.yaml | 193 - .../nyaml/NXcs_memory.yaml | 63 - contributed_definitions/nyaml/NXcs_prng.yaml | 134 - .../nyaml/NXcs_process.yaml | 78 - .../nyaml/NXcs_profiling.yaml | 263 -- .../nyaml/NXcs_profiling_event.yaml | 159 - .../nyaml/NXcs_storage.yaml | 62 - .../nyaml/NXebeam_column.yaml | 428 --- .../nyaml/NXellipsometry.yaml | 701 ---- contributed_definitions/nyaml/NXem.yaml | 3177 ----------------- contributed_definitions/nyaml/NXem_ebsd.yaml | 1178 ------ contributed_definitions/nyaml/NXem_eds.yaml | 336 -- contributed_definitions/nyaml/NXem_eels.yaml | 84 - contributed_definitions/nyaml/NXem_img.yaml | 98 - .../nyaml/NXem_measurement.yaml | 41 - .../nyaml/NXem_simulation.yaml | 44 - .../nyaml/NXevent_data_apm.yaml | 308 -- .../nyaml/NXevent_data_em.yaml | 286 -- .../nyaml/NXibeam_column.yaml | 233 -- contributed_definitions/nyaml/NXimage.yaml | 1086 ------ .../nyaml/NXinstrument_apm.yaml | 672 ---- .../nyaml/NXinstrument_em.yaml | 409 --- .../nyaml/NXinteraction_volume_em.yaml | 92 - contributed_definitions/nyaml/NXion.yaml | 184 - ..._electro_chemo_mechanical_preparation.yaml | 310 -- .../nyaml/NXlab_sample_mounting.yaml | 151 - .../NXmicrostructure_gragles_config.yaml | 656 ---- .../NXmicrostructure_gragles_results.yaml | 510 --- .../nyaml/NXmicrostructure_imm_config.yaml | 421 --- .../nyaml/NXmicrostructure_imm_results.yaml | 329 -- .../nyaml/NXoptical_lens.yaml | 309 -- .../nyaml/NXoptical_spectroscopy.yaml | 1963 ---------- .../nyaml/NXoptical_system_em.yaml | 295 -- .../nyaml/NXoptical_window.yaml | 206 -- contributed_definitions/nyaml/NXphase.yaml | 122 - contributed_definitions/nyaml/NXprogram.yaml | 68 - contributed_definitions/nyaml/NXpump.yaml | 58 - contributed_definitions/nyaml/NXraman.yaml | 398 --- contributed_definitions/nyaml/NXroi.yaml | 62 - .../nyaml/NXrotations.yaml | 439 --- .../nyaml/NXsample_component_set.yaml | 123 - .../nyaml/NXscanbox_em.yaml | 141 - contributed_definitions/nyaml/NXspectrum.yaml | 934 ----- .../nyaml/NXunit_cell.yaml | 267 -- .../nyaml/NXwaveplate.yaml | 276 -- 154 files changed, 17 insertions(+), 42280 deletions(-) delete mode 100644 contributed_definitions/NXaberration.nxdl.xml delete mode 100644 contributed_definitions/NXapm.nxdl.xml delete mode 100644 contributed_definitions/NXapm_charge_state_analysis.nxdl.xml delete mode 100644 contributed_definitions/NXapm_measurement.nxdl.xml delete mode 100644 contributed_definitions/NXapm_ranging.nxdl.xml delete mode 100644 contributed_definitions/NXapm_reconstruction.nxdl.xml delete mode 100644 contributed_definitions/NXapm_simulation.nxdl.xml delete mode 100644 contributed_definitions/NXatom.nxdl.xml delete mode 100644 contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml delete mode 100644 contributed_definitions/NXcg_alpha_complex.nxdl.xml delete mode 100644 contributed_definitions/NXcg_cylinder.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_grid.nxdl.xml delete mode 100644 contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyline.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive.nxdl.xml delete mode 100644 contributed_definitions/NXcg_roi.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle.nxdl.xml delete mode 100644 contributed_definitions/NXcg_unit_normal.nxdl.xml delete mode 100644 contributed_definitions/NXchemical_composition.nxdl.xml delete mode 100644 contributed_definitions/NXcircuit.nxdl.xml delete mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml delete mode 100644 contributed_definitions/NXcs_computer.nxdl.xml delete mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 contributed_definitions/NXcs_memory.nxdl.xml delete mode 100644 contributed_definitions/NXcs_prng.nxdl.xml delete mode 100644 contributed_definitions/NXcs_process.nxdl.xml delete mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml delete mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml delete mode 100644 contributed_definitions/NXcs_storage.nxdl.xml delete mode 100644 contributed_definitions/NXebeam_column.nxdl.xml delete mode 100644 contributed_definitions/NXellipsometry.nxdl.xml delete mode 100644 contributed_definitions/NXem.nxdl.xml delete mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml delete mode 100644 contributed_definitions/NXem_eds.nxdl.xml delete mode 100644 contributed_definitions/NXem_eels.nxdl.xml delete mode 100644 contributed_definitions/NXem_img.nxdl.xml delete mode 100644 contributed_definitions/NXem_measurement.nxdl.xml delete mode 100644 contributed_definitions/NXem_simulation.nxdl.xml delete mode 100644 contributed_definitions/NXevent_data_apm.nxdl.xml delete mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml delete mode 100644 contributed_definitions/NXibeam_column.nxdl.xml delete mode 100644 contributed_definitions/NXimage.nxdl.xml delete mode 100644 contributed_definitions/NXinstrument_apm.nxdl.xml delete mode 100644 contributed_definitions/NXinstrument_em.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_volume_em.nxdl.xml delete mode 100644 contributed_definitions/NXion.nxdl.xml delete mode 100644 contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml delete mode 100644 contributed_definitions/NXlab_sample_mounting.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_results.nxdl.xml delete mode 100644 contributed_definitions/NXoptical_lens.nxdl.xml delete mode 100644 contributed_definitions/NXoptical_spectroscopy.nxdl.xml delete mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml delete mode 100644 contributed_definitions/NXoptical_window.nxdl.xml delete mode 100644 contributed_definitions/NXphase.nxdl.xml delete mode 100644 contributed_definitions/NXprogram.nxdl.xml delete mode 100644 contributed_definitions/NXpump.nxdl.xml delete mode 100644 contributed_definitions/NXraman.nxdl.xml delete mode 100644 contributed_definitions/NXroi.nxdl.xml delete mode 100644 contributed_definitions/NXrotations.nxdl.xml delete mode 100644 contributed_definitions/NXsample_component_set.nxdl.xml delete mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml delete mode 100644 contributed_definitions/NXspectrum.nxdl.xml delete mode 100644 contributed_definitions/NXunit_cell.nxdl.xml delete mode 100644 contributed_definitions/NXwaveplate.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXaberration.yaml delete mode 100644 contributed_definitions/nyaml/NXapm.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_measurement.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_ranging.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_reconstruction.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_simulation.yaml delete mode 100644 contributed_definitions/nyaml/NXatom.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_cylinder.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.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.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_parallelogram.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_point.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polygon.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyhedron.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyline.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_primitive.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_roi.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_triangle.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_unit_normal.yaml delete mode 100644 contributed_definitions/nyaml/NXchemical_composition.yaml delete mode 100644 contributed_definitions/nyaml/NXcircuit.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_filter_boolean_mask.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_memory.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_prng.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_process.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/NXcs_storage.yaml delete mode 100644 contributed_definitions/nyaml/NXebeam_column.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_eds.yaml delete mode 100644 contributed_definitions/nyaml/NXem_eels.yaml delete mode 100644 contributed_definitions/nyaml/NXem_img.yaml delete mode 100644 contributed_definitions/nyaml/NXem_measurement.yaml delete mode 100644 contributed_definitions/nyaml/NXem_simulation.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em.yaml delete mode 100644 contributed_definitions/nyaml/NXibeam_column.yaml delete mode 100644 contributed_definitions/nyaml/NXimage.yaml delete mode 100644 contributed_definitions/nyaml/NXinstrument_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXinstrument_em.yaml delete mode 100644 contributed_definitions/nyaml/NXinteraction_volume_em.yaml delete mode 100644 contributed_definitions/nyaml/NXion.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/NXmicrostructure_gragles_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_lens.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_spectroscopy.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_system_em.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_window.yaml delete mode 100644 contributed_definitions/nyaml/NXphase.yaml delete mode 100644 contributed_definitions/nyaml/NXprogram.yaml delete mode 100644 contributed_definitions/nyaml/NXpump.yaml delete mode 100644 contributed_definitions/nyaml/NXraman.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml delete mode 100644 contributed_definitions/nyaml/NXrotations.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_component_set.yaml delete mode 100644 contributed_definitions/nyaml/NXscanbox_em.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum.yaml delete mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml delete mode 100644 contributed_definitions/nyaml/NXwaveplate.yaml diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml index 6d8bb84e01..b1ca7175f4 100644 --- a/applications/NXem.nxdl.xml +++ b/applications/NXem.nxdl.xml @@ -801,7 +801,7 @@ - + @@ -809,7 +809,7 @@ - + @@ -944,7 +944,7 @@ - + diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml index 797ffcdb66..907f758bc7 100644 --- a/applications/nyaml/NXem.yaml +++ b/applications/nyaml/NXem.yaml @@ -667,6 +667,7 @@ NXem(NXobject): vendor(NX_CHAR): model(NX_CHAR): serial_number(NX_CHAR): + exists: recommended blankerID(NXdeflector): nameType: partial exists: ['min', '0', 'max', 'unbounded'] @@ -676,6 +677,7 @@ NXem(NXobject): vendor(NX_CHAR): model(NX_CHAR): serial_number(NX_CHAR): + exists: recommended monochromatorID(NXmonochromator): exists: ['min', '0', 'max', 'unbounded'] nameType: partial @@ -844,6 +846,7 @@ NXem(NXobject): vendor(NX_CHAR): model(NX_CHAR): serial_number(NX_CHAR): + exists: recommended gas_injector(NXcomponent): exists: optional fabrication(NXfabrication): @@ -1744,7 +1747,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3c3c9ee91b0f8fdeca130b72ff8c51ce1699a8b63ac5e9416189986c0ff94a50 +# 088f012252ec11ab2c0e39934800192e6831472728e0c3a2120a8d4998576d5b # # # - + In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and diff --git a/base_classes/nyaml/NXinstrument_em.yaml b/base_classes/nyaml/NXinstrument_em.yaml index 017c0c4e0b..dbc0c376b6 100644 --- a/base_classes/nyaml/NXinstrument_em.yaml +++ b/base_classes/nyaml/NXinstrument_em.yaml @@ -56,6 +56,7 @@ NXinstrument_em(NXinstrument): Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. stageID(NXmanipulator): + nameType: partial doc: | Stages in an electron microscope are multi-functional devices. @@ -166,6 +167,7 @@ NXinstrument_em(NXinstrument): rank: 1 dim: (3,) nanoprobeID(NXmanipulator): + nameType: partial doc: | In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and @@ -181,7 +183,7 @@ NXinstrument_em(NXinstrument): (NXactuator): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bed215d44373898c878e4aad6fd9f0e6ef16df6855413ad14bfad54121649f40 +# 7b6147010ffb3dfb1a9fa99c941eecc8602c11cbd0bcb2c1887678436af0a5a1 # # # - - - Quantified aberration coefficient in an aberration_model. - - For an introduction in the aberrations in electron microscopy - see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and - `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. - Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. - - - - Magnitude of the aberration - - - - - Uncertainty of the magnitude of the aberration - - - - - Free-text description how magnitude_errors was quantified - e.g. via the 95% confidence interval, variance, standard deviation, - using which algorithm or statistical model. - - - - - Time elapsed since the last measurement. - - - - - 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. - - - - - Given name to this aberration. - - - - - Alias to name or refer to this specific type of aberration. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml deleted file mode 100644 index d7258e6830..0000000000 --- a/contributed_definitions/NXapm.nxdl.xml +++ /dev/null @@ -1,1309 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of hit qualities (hit types) distinguished. - - - - - Number of delay-line wires of the detector. - - - - - Number of bins used in the mass-to-charge-state-ratio spectrum. - - - - - Number of pulses collected in between start_time and end_time resolved by an - instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. - - - - - Number of pulses returned by the hit finding algorithm. - Neither necessarily equal to p nor to n. - - - - - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_id). This identifier must not be confused with - the pulse_id. Typically smaller than both p_out and p_out. - - - - - Application definition for atom probe and field ion microscopy experiments. - - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. - - - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - - - - - - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually 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 (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored via NXnote in the - hit_finding algorithm section. - - 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. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. - - - - - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping 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. For this - purpose the :ref:`NXevent_data_apm` instance should be used. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. - - - - - How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime - - - - - - - - - - - - - - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * 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. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. - - - - - - - - - - - - - - - - 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 knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - 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. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. - - - - - Qualifier whether the sample is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - - - - - Given name/alias for the sample. - - - - - 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. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. - - - - - Magnitude of the standard deviation of 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 a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. - - - - - Magnitude of the standard deviation of the heat_treatment_temperature. - - - - - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging aluminum samples left on the factory - parking lot on a hot summer day. - - - - - Magnitude of the 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. - - - - - - - - - - - - - - Qualifier whether the specimen is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - - - - - Given name an alias. Better use identifierNAME and identifier_parent instead. - A single NXentry should be used only for the characterization of a single specimen. - - - - - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. - - - - - 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. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by identifier_parent. - - 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. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not - pollute the description here with prose. Resolving these connected - pieces of information is considered within the responsibility of the - research data management system. - - - - - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by identifier_parent or walk through - eventually deeply nested groups in data instances. - - - - - Discouraged free-text field. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - Report if the specimen is amorphous. - - - - - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. - - - - - Ideally measured otherwise best elaborated guess of the (initial) 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. - - - - - - The conventions used when reporting crystal orientations. - We follow the best practices of the Material Science community - that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - - A collection of coordinate systems. Several Euclidean - coordinate systems (CS) are used in the field of atom probe: - - * 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. - - 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 identifier interval. Typically, the set of - ion evaporation sequence identifiers 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. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. - - - - - - - - - - - - Base class for collecting a session with a real atom probe or field-ion microscope. - - Workflows used during experiments or simulations of atom probe and related field-evaporation - research should be documented in more detail and be better contextualized not only because of - ongoing developments and the tighter becoming connection between atom probe and other - methods for material characterization foremost electron microscopy see e.g.: - - * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ - * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ - * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ - * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ - - to mention but a few. - - To arrive at a design of base classes and an application definition that can be used - for both real and simulated atom probe experiments it is worthwhile to recall concepts that are - related to events and (molecular) ions: - - * Pulsing events which are used to trigger ion extraction events. - * Physical events and corresponding signal triggered by an ion hitting the detector. - Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. - * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input - and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are - worthwhile to be considered further and eventually included in the reconstructed volume. - * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually - selected (molecular) ions based on which an instance of a reconstruction is created. - * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values - and charge states of the (molecular) ions to substantiate that some of these ions can be considered - as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms - and subsequent peak labeling. In the field of atom probe this these peak identification methods - are known as ranging definitions. - - Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts - are well distinguished. However, the algorithms used to transform correlations between pulses and physical events - into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm. - - Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme - where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier - i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. - That is evaporation_id values take the role of an implicit time and course of the experiment given that - ion extraction physically is a sequential process. - - There is a number of research groups who build own instruments and share different aspects of their technical - specifications and approaches how they apply data processing e.g.: - - * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ - * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ - * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ - - to name but a few. - - Despite some of these activities embrace practices of open-source development, they use essentially the same - workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface - software is used to explore and thus analyze reconstructed atom probe datasets. - - Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. - Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which - scientific conclusions about the characterized material volume are made. Also here a reconstruction is - point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model. - - By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all - the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. - Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. - We argue that this divide can be bridged with realizing the above-mentioned context and the realization that - similar concepts are used in both research realms with many concepts not only being similar but being exactly the same. - - A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed - datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment - and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting - a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as - (spatial) filtering and reconstruction algorithms. - - Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation - simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. - Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. - Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. - Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require - simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps - in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. - Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) - than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path - such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - CAnalysis.CResults.fQuality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Free text field for additional comments. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Simulation of ion extraction from matter via laser and/or voltage pulsing. - - - - - - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. - - - - - SEM or TEM image of the initial specimen (ideally taken prior data acquisition). - - - - - - - - - - - - - - - - - - - - - - - - For almost atom probe instruments (meta)data about raw data follow proprietary semantics. - Therefore, this group can currently be used only to point to these digital artifacts - in an effort to document all step of an analysis workflow. - - The physical quantities measured in an atom probe experiment are time-of-flight and - tuples of arrival_time_pairs as a function of the event chain on the pulser. - From these tuples hits are computed in a process called hit_finding. - - - - - - - - - - - - - - - - - - The number of wires in the detector. - - - - - - - - - - Alias tuple (begin, end) of each DLD wire of the detector. - Order follows arrival_time_pairs. - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - - Configuration of and results obtained from a hit finding algorithm. - - - - - - - - - - - - - - - - - - - Evaluated ion impact coordinates on the detector. - Use the depends_on field to specify which reference - frame the positions are defined. - - - - - - - - Defines in which reference frame the positions are defined. - - - - - - CRunHeader.fTotalEventGolden - - - - - CRunHeader.fTotalEventIncomplete - - - - - CRunHeader.fTotalEventMultiple - - - - - CRunHeader.fTotalEventPartials - - - - - CRunHeader.fTotalEventRecords - - - - - Hit quality is an integer that specifies which category/type a hit was assigned to. - This field lists the human-readable, possibly though proprietary types distinguished. - The indices of this array are used in hit_quality to encode hit_quality for each - pulse in a more efficient way than by repeating the string that is used for each - type as it is provided in this field. - - As an example assume two types golden and partial are distinguished. - If hit_quality_type stores the array "golden", "partial", the index 0 - in hit_quality identifies all those pulses of category golden, - while the index 1 in hit_quality identifies all of category partial. - - - - - - - - Hit quality identifier for each pulse. - Identifier have to be within hit_quality. - - - - - - - - This processing yields for each ion with how many others it evaporated - if these were collected on the same pulse. Extraction of multiple ions - on one pulse on different or even the same pixel of the detector are possible. - - Multiplicity must not be confused with how many atoms of the same element - a molecular ion contains. - - - - - - - - - - - - - - - - - - - - - - - Integer used to name the first pulse to know if there is an - offset of the evaporation_id to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - evaporation_id_offset and cardinality. For example if identifier run from - -2 to 3 the value for evaporation_id_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where evaporation_id_offset is 1 and 0 respectively. - - - - - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. - - - - - - - - - - - - - - - - - Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. - - The voltage-and-bowl correction is a data post-processing step to correct ion impact - positions for flight path differences, detector bias, and nonlinearities. - - - - - - - - - - - - - - - - - Raw time-of-flight data without corrections. - - - - - - - - - The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate - - - - - Calibrated time-of-flight. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. - - - - - - - - - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The respective ranging definitions file RNG/RRNG/ENV/HDF5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. - - - - - MRP, mass-resolving power, `D. Larson et al. - <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). - - - - - MRP, at which mrp_value was specified. - - - - - - - - - - - - - - - - - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml deleted file mode 100644 index 92bc619537..0000000000 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of also possible but different (molecular) ions. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - - - - - Number of entries - - - - - Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. - - Currently ranging definitions in the research field of atom probe face have limitations: - - 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio - values, though, for which not only multiple (molecular) ions are indistinguishable but - also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Indeed, ranging definitions often report only (for each interval) the - mass-to-charge-state-ratio intervals surplus the composition of elements - that build the (molecular) ion. - 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify nuclides from which the (molecular) ion is constructed - and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. - - This base class documents the configuration and results of such an algorithm. - - - - - Input constraint, list of nuclide_hash for typically elements used for the - ranging definition of the ion whose charge state the analyses covered. - The list contains each hash as many times as its multiplicity. - Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. - - As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. - An empty list does not release the constraint. Instead, a list with all elements - in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. - - Keep in mind that with a weakly constrained parameter space the combinatorial - analysis may become very time consuming! - - - - - - - - Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that an ion qualifies as a candidate. - - - - - - - - - Input constraint, minimum half life for how long each nuclide of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - - - - - Input constraint, minimum natural abundance of each nuclide of each - (molecular) ion such that the ion qualifies as a candidate. - - - - - If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from - different nuclide instances but the charge_state of all the ions is the same. - - - - - - - Signed charge, i.e. integer multiple of the elementary - charge of each candidate. - - - - - - - - Table of nuclide instances of which each candidate is composed. - Each row vector is sorted in descending order. Unused values are nullified. - - - - - - - - - Accumulated mass of the nuclides in each candidate. - Not corrected for quantum effects. - - - - - - - - The product of the natural abundances of the nuclides for each candidate. - - - - - - - - For each candidate the half life of that nuclide which has the shortest half - life. - - - - - - diff --git a/contributed_definitions/NXapm_measurement.nxdl.xml b/contributed_definitions/NXapm_measurement.nxdl.xml deleted file mode 100644 index de28bb60c5..0000000000 --- a/contributed_definitions/NXapm_measurement.nxdl.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - Base class for documenting a measurement with an atom probe microscope. - - - - diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml deleted file mode 100644 index 9ae8bcd82b..0000000000 --- a/contributed_definitions/NXapm_ranging.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - Base class for the configuration and results of ranging definitions. - - Ranging is a data post-processing step used in the research field of - atom probe during which elemental, isotopic, and/or molecular identities - are assigned to mass-to-charge-state-ratios within a certain interval. - The documentation of these steps is based on ideas that - have been 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>`_ - - - - - - Specifies the mass-to-charge-state-ratio histogram. - - - - - Smallest, increment, and largest mass-to-charge-state ratio value. - - - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - Details of the background model that was used to - correct the total counts per bin into counts. - - - - - To begin with we use a free-text field to learn how - atom probers define a background model. Future versions - of NXapm_ranging can then use this information to parameterize - these models. - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - 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 representing 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 (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). - - - - - diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml deleted file mode 100644 index 44885301a9..0000000000 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process - the so-called - evaporation_id, which must not be confused with the pulse_id! - - - - - Base class for the configuration and results of a (static) reconstruction algorithm. - - Generating a tomographic reconstruction of the specimen uses selected and - 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. - - - - - - - - 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 this free-text field to guide how to parameterize this better in the - future. For LEAP systems and reconstructions performed with IVAS/APSuite - see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). - - - - - CAnalysis.CSpatial.fPrimaryElement - - - - - CAnalysis.CSpatial.fEfficiency - - - - - CAnalysis.CSpatial.fFlightPath - - - - - CAnalysis.CSpatial.fEvaporationField - - - - - CAnalysis.CSpatial.fImageCompression - - Image compression factor (ICF) - - - - - CAnalysis.CSpatial.fKfactor - - k factor - - - - - CAnalysis.CSpatial.fRecoVolume - - Sum of ion volumes - - - - - CAnalysis.CSpatial.fShankAngle - - Shank angle - - - - - CAnalysis.CSpatial.fTipRadius - - - - - CAnalysis.CSpatial.fTipRadius0 - - - - - CAnalysis.CSpatial.fVoltage0 - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. Therefore, we collect first such - feedback before parametrizing this further. - - If no crystallographic calibration was performed, the field - should be filled with the n/a, meaning not applied. - - - - - Tight, axis-aligned bounding box about the point cloud of the reconstruction. - - - - TODO - - - - - TODO - - - - - TODO - - - - - TODO - - - - - TODO - - - - - TODO - - - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. The physical specimen cannot be measured completely - because ions may launch but hit in locations other than the detector. - - - - - Three-dimensional reconstructed positions of the ions. - - - - - - - - The instance of :ref:`NXcoordinate_system` - in which the positions are defined. - - - - - - - - - To get a first visual overview of the reconstructed dataset, - here a 3d histogram of the ion is stored. Ion counts are characterized - using one nanometer cubic bins without applying position smoothening - algorithms during the histogram computation. - - - - diff --git a/contributed_definitions/NXapm_simulation.nxdl.xml b/contributed_definitions/NXapm_simulation.nxdl.xml deleted file mode 100644 index 78a2b757c1..0000000000 --- a/contributed_definitions/NXapm_simulation.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - Base class for documenting a simulation of removing ions from a specimen and - characterizing them. - - - - - - diff --git a/contributed_definitions/NXatom.nxdl.xml b/contributed_definitions/NXatom.nxdl.xml deleted file mode 100644 index b57489ca1a..0000000000 --- a/contributed_definitions/NXatom.nxdl.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of atom positions. - - - - - Dimensionality - - - - - Base class for documenting a set of atoms. - - Atoms in the set may be bonded. The set may have - a net charge to represent an ion. - An ion can be a molecular ion. - - - - Given name for the set. - - This field could for example be used in the research field - of atom probe tomography to store a standardized human-readable - name of the element or (molecular) ion like such as Al +++ or 12C +. - - - - - Identifier used to refer to if the set of atoms represents a substance. - - - - - - - - Signed net (partial) charge of the (molecular) ion. - - Different methods for computing charge are in use. - Care needs to be exercised with respect to the integration. - `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. - - - - - Charge reported in multiples of the charge of an electron. - - For research using atom probe tomography the value should be set to - zero if the charge_state is unknown and irrecoverable. This can happen - when classical ranging definition files in formats like RNG, RRNG are used. - These file formats do not document the charge state explicitly but only - the number of atoms of each element per molecular ion surplus the - respective mass-to-charge-state-ratio interval. - - Details on ranging definition files in the literature are `M. K. Miller <https://doi.org/10.1002/sia.1719>`_. - - - - - Assumed volume affected by the set of atoms. - - Neither individual atoms nor a set of cluster of these have a volume - that is unique as a some cut-off criterion is required. - - - - - Index for each atom at locations as detailed by position. - Indices can be used as identifier and thus names for individual atoms. - - - - - - - - Nuclide information for each atom at locations as detailed by position. - - One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information - efficiently is via hashing with the following formula - - :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - - the number of protons and :math:`N` the number of neutrons - of each nuclide given as 8-bit unsigned integer values. - - - - - - - - Position of each atom. - - - - - - - - Path to a reference frame in which positions are defined - to resolve ambiguity when the reference frame is different - to the NeXus default reference frame (McStas). - - - - - - Relative occupancy of the atom position. - - This field is useful for specifying the atomic motif in - instances of :ref:`NXunit_cell`. - - - - - - diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml deleted file mode 100644 index 583f7072db..0000000000 --- a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the array associated to the data type. - - - - - Contains data structures of an experimental optical setup (i.e., multiple - transfer matrix tables). These data structures are used to relate physical - properties of two beams (NXbeam) which have one common optical component - (NXcomponent) (one specific transfer matrix). - One of these beams is an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. - - - - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - - - - - - - - - - - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - - - - - - - - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfer matrix relationship between N input beams and M output beams. - It contains a table with the relevant matrices to be used for different - transmitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of a beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfer matrix table has the dimension NxM. - - For each entry, in this transfer matrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfer matrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - - - - - - - - Specific name of input beam which the transfer matrix table is related to. - - - - - Specific name of output beam which the transfer matrix table is related to. - - - - \ No newline at end of file diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml deleted file mode 100644 index 124b20ebbc..0000000000 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - - Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about 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 of alpha shapes, and - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings - - in CGAL, the Computational Geometry Algorithms Library respectively. - As a starting point, we follow the conventions of the CGAL library. - - In general, an alpha complex is a not necessarily connected or not necessarily pure complex, - i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific - alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and - regularization can be used to provide details about regularization procedures. - - - - Type of alpha complex following the terminology used by CGAL for now. - - Alpha_shape means meshes created using one of the alpha_shape algorithm. - Alpha_wrapping means meshes created using the alpha_wrapping algorithm. - - - - - - - - - - Human-readable description about regularization procedures. - - - - - Was the alpha complex regularized, i.e. have singular faces been removed, or not. - - - - - The alpha parameter, i.e. the squared radius of the alpha-sphere - that is used when computing the alpha complex. - - - - - The offset distance parameter used when computing alpha_wrappings. - - - - - - Point cloud serving as input for the computation of the alpha complex. - - - - - Triangle soup serving as input for the computation of the alpha complex. - - - - - Triangle mesh representing the output of the computation, i.e. the alpha complex. - - - - - Tetrahedra representing an interior volume of the alpha complex (if such exists). - - - diff --git a/contributed_definitions/NXcg_cylinder.nxdl.xml b/contributed_definitions/NXcg_cylinder.nxdl.xml deleted file mode 100644 index 2459121170..0000000000 --- a/contributed_definitions/NXcg_cylinder.nxdl.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the space in which the members are assumed embedded. - - - - - The cardinality of the set, i.e. the number of members. - - - - - Computational geometry description of a set of cylinders or (truncated) cones. - - The radius can either be defined in the radii field or by filling the upper_cap_radii - and lower_cap_radii fields respectively. The latter field case can - thus be used to represent (truncated) cones. - - It is possible to define only one of the cap_radii fields - to represent half-open cylinder. - - - - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. - - The upper_cap is assumed to represent the end while the - lower_cap is assumed to represent the start of the - respective cylinder instances when inspecting along the - direction vector. - - - - - - - - - Radius of the cylinder if all have the same radius. - - - - - Radii of the cylinder. - - - - - - - - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. - - - - - - - - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. - - - - - - - - - Lateral surface area of each cylinder. - - - - - - - - Area of the upper cap of each cylinder. - - - - - - - - Area of the lower cap of each cylinder. - - - - - - - - Sum of upper and lower cap area and lateral surface area of each cylinder. - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid.nxdl.xml b/contributed_definitions/NXcg_ellipsoid.nxdl.xml deleted file mode 100644 index c34a4897e7..0000000000 --- a/contributed_definitions/NXcg_ellipsoid.nxdl.xml +++ /dev/null @@ -1,81 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the space in which the members are assumed embedded. - - - - - The cardinality of the set, i.e. the number of members. - - - - - Computational geometry description of a set of ellipsoids. - - - - Length of the semi-axes (e.g. semi-major and semi-minor - respectively for an ellipse). - - Use if all ellipsoids in the set have the same half-axes. - - - - - - - - Length of the semi-axes if ellipsoids have individually different lengths. - - - - - - - - - - In the case that all ellipsoids are spheres. - - - - - In the case that all ellipsoids are spheres whose radii differ. - For a mixture of spheres use semi_axes_values. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index 5fcfde6822..0000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,227 +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. - - - - - Computational geometry of primitives via a face-and-edge-list data structure. - - Primitives must neither be degenerated nor self-intersect but can have different - properties. A face-and-edge-list-based description of primitives is - frequently used for triangles and polyhedra to store them on disk for - visualization purposes (see OFF, PLY, VTK, or STL file formats). - - Although this description is storage efficient, it is not well-suited for - topological analyses. In this case using a half-edge data structure is - an alternative. - - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or detailed specification demands. - - Indices can be used as identifier and thus names for individual instances. - - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Number of faces of the primitives. - - - - - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - - - - - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - - - - - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - - - - - Integer identifier to distinguish all vertices explicitly. - - - - - - - - Integer used to distinguish all edges explicitly. - - - - - - - - Integer used to distinguish all faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in more efficient storage. Alternatively, storing vertex positions naively - should be indicated with setting vertices_are_unique to False. - Naively means that each vertex is stored even though many vertices may - share the same positions. - - - - - - - - - The edges are stored as pairs of vertex identifier. - - - - - - - - - The faces are stored as a concatenated array of vertex identifier tuples. - - 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: :math:`[\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 more - than once. - - - - - If true, indicates that no edge is stored more than once. - - Users are encouraged to consider using a half_edge_data_structure instead. - - - - - If true, indicates that no face is stored more than once. - - - - - 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_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml deleted file mode 100644 index d0a9863a9e..0000000000 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ /dev/null @@ -1,178 +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 aka grid points. - - - - - Number of boundaries of the bounding box or primitive housing the grid. - - - - - Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - - Three-dimensional grids with cubic cells are if not the most frequently used - example of such grids. Numerical methods and models that use grids are used - in many cases in the natural sciences and engineering disciplines. Examples are - discretizations in space and time used for phase-field, cellular automata, or Monte Carlo - modeling. - - - - Location of the origin of the grid. - - Use the depends_on field that is inherited from the :ref:`NXcg_primitive` - class to specify the coordinate system in which the origin location is defined. - - - - - - - - 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. - - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - Coordinate of each cell with respect to the discrete grid. - - - - - - - - - - A tight bounding box about the grid. - - - - - - Number of boundaries distinguished - - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - Name of domain boundaries of the simulation box/ROI - 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 - - - - - - - - - Details about the computational geometry method and implementation - used for discretizing internal surfaces as e.g. obtained with marching methods, - like marching squares or marching cubes. - - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. - 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 ideally be an identifier of a program. - If not possible, an identifier for a paper, technical report, or free-text - description can be used instead. - - - diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml deleted file mode 100644 index 91eb74bc44..0000000000 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ /dev/null @@ -1,195 +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 geometry 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. The data structure is also - known as a doubly connected edge list. - - Indices can be used as identifier and thus names for individual instances. - - - - Dimensionality of the primitives described. - - - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - - - - - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - - - - - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - - - - - - 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.nxdl.xml b/contributed_definitions/NXcg_hexahedron.nxdl.xml deleted file mode 100644 index 2684550116..0000000000 --- a/contributed_definitions/NXcg_hexahedron.nxdl.xml +++ /dev/null @@ -1,191 +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. - - 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 an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional 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. - - As a specialization of the :ref:`NXcg_primitive` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making 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 - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - Qualifier for the shape of each hexahedron. - - - - - - - - - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. - - - - - - - - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. - - - - - - - - Volume of each hexahedron. - - - - - - - - Total (surface) 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 coordinate system. - - - - - - - - - - - - Combined storage of all primitives of all hexahedra. - - - - - Individual storage of each hexahedron. - - - - - Individual storage of each hexahedron as a graph. - - - diff --git a/contributed_definitions/NXcg_parallelogram.nxdl.xml b/contributed_definitions/NXcg_parallelogram.nxdl.xml deleted file mode 100644 index f54790ce5f..0000000000 --- a/contributed_definitions/NXcg_parallelogram.nxdl.xml +++ /dev/null @@ -1,101 +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. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing 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, i.e. - most tightly 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 an optimal bounding box to a point set in 2D. - - - - - To specify which parallelogram is a rectangle. - - - - - - - - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. - - - - - - - - - Combined storage of all parallelograms. - - - - - Individual storage of each parallelogram. - - - diff --git a/contributed_definitions/NXcg_point.nxdl.xml b/contributed_definitions/NXcg_point.nxdl.xml deleted file mode 100644 index 169abbe893..0000000000 --- a/contributed_definitions/NXcg_point.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points. - - Points may have an associated time value. Users are advised though to store - time data of point sets rather as instances of time events, where for each - point in time there is an :ref:`NXcg_point` 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 (real time or - simulated physical time). Thereby, the storage of redundant timestamp - information per point is considered as obsolete. - - - - Coordinates of the points. - - - - - - - - - (Elapsed) time for each point. - - If the field time is needed contextualize the time_offset relative to which - time values are defined. Alternative store timestamp. - - - - - - - - ISO8601 with local time zone offset for each point. - - - - - - - - ISO8601 with local time zone offset that serves as the reference - for values in the field time. - - - diff --git a/contributed_definitions/NXcg_polygon.nxdl.xml b/contributed_definitions/NXcg_polygon.nxdl.xml deleted file mode 100644 index 9c30549668..0000000000 --- a/contributed_definitions/NXcg_polygon.nxdl.xml +++ /dev/null @@ -1,126 +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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes 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 to describe such even more complex primitives instead - of abusing this base class for such purposes. - - - - The total number of vertices in the set. - - - - - - Combined storage of all primitives of all polygons. - - - - - Individual storage of the mesh of each polygon. - - - - - Individual storage of each polygon as a graph. - - - - - - For each polygon its accumulated length along its edges. - - - - - - - - Interior angles for each polygon. There are as many values per polygon - as the are 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 - - - - - - diff --git a/contributed_definitions/NXcg_polyhedron.nxdl.xml b/contributed_definitions/NXcg_polyhedron.nxdl.xml deleted file mode 100644 index 2908ee8345..0000000000 --- a/contributed_definitions/NXcg_polyhedron.nxdl.xml +++ /dev/null @@ -1,114 +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 set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon`. - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. - - - - - - - - Area of each of faces. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counted for each polyhedron. - - - - - Length of each edge. - - - - - - - - - Combined storage of all primitives of all polyhedra. - - - - - Individual storage of each polyhedron. - - - - - Individual storage of each polygon as a graph. - - - diff --git a/contributed_definitions/NXcg_polyline.nxdl.xml b/contributed_definitions/NXcg_polyline.nxdl.xml deleted file mode 100644 index f5e247c756..0000000000 --- a/contributed_definitions/NXcg_polyline.nxdl.xml +++ /dev/null @@ -1,140 +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. - - 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 traversal along the polyline when - walking from the first to the last vertex. - - - - Reference to an instance of :ref:`NXcg_point` which defines the - location of the vertices that are referred to in this - NXcg_polyline instance. - - - - - The total number of vertices that have different positions. - - - - - The total number of vertices, irrespective of their eventual uniqueness. - - - - - The total number of vertices of each polyline, irrespectively - whether vertices are shared by vertices or not. - - - - - - - - - Positions of the vertices which support the members of the polyline set. - - Users are encouraged to reduce the vertices to unique positions and vertices - as this often supports with storing geometry data more efficiently. - 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 stores each vertex of a triangle mesh - even though many vertices are shared between triangles and thus - storing multiple copies of their positions is redundant. - - - - - - - - - If true indicates that the vertices are all placed at different - positions and have different identifiers, i.e. no points overlap - or are counted several times. - - - - - Sequence of identifier for vertices how they build each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet at a vertex (assume for example that the second vertex - is shared and marking the junction between the two polylines), it is possible - that there are only five unique positions. This suggests to store five - unique vertices. - - A non-trivial example is a set with several polylines. Assume that each - has a different number of vertices. The array stores the identifier of - the vertices in the sequence how the polylines are visited: - - The first entry is the identifier of the first vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the first polyline. - Thereafter, the first vertex of the second polyline, and so on and so forth. - Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), - the vertices of the N-th polyline can be accessed on the array - index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. - - - - - - diff --git a/contributed_definitions/NXcg_primitive.nxdl.xml b/contributed_definitions/NXcg_primitive.nxdl.xml deleted file mode 100644 index 2f096e316d..0000000000 --- a/contributed_definitions/NXcg_primitive.nxdl.xml +++ /dev/null @@ -1,247 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the embedding space. - - - - - The cardinality of the set, i.e. the number of members. - - - - - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). - - - - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives - are defined. - - - - - The dimensionality of the primitive set with value up to d. - - - - - - - - - - - The cardinality of the primitive set. Value should be equal to c. - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Indices can be used as identifiers and thus names of instances. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - index_offset and cardinality. For example if identifier run from - -2 to 3 the value for index_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where index_offset is 1 and 0 respectively. - - - - - Identifier of each member for explicit indexing. - - - - - - - - The center of each primitive - - - - - - - - - True if the center is a center of mass. - - - - - - - - Shape of each primitive - - - - - - - - - Length of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - - - - - - - - Width of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - - - - - - - - Height of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - - - - - - - - True if primitive is closed such that it has properties like area or volume. - - - - - - - - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - Volume is an N-D concept for values of dimensionality larger than 1, - Area is an alias for the two-dimensional case. - - - - - - - - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - - - - - - - - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - - - - - - - - - Do the primitives define a mesh. - - - - - Do the primitives define a triangle mesh or not. - - - - - Do the primitives discretize the surface of an object or not. - - - - - Do the primitives define a geodesic mesh or not. - - A geodesic surface mesh is a triangulated surface mesh with metadata which - can be used as an approximation to describe the surface of a sphere. - Triangulation of spheres are commonly used in Materials Science - for quantifying texture of materials, i.e. the relative rotation of - crystals to sample directions. - - For additional details or an introduction into the topic of geodesic meshes - see (from which specifically the section on subdivision schemes is relevant). - - * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - - Earth scientists 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 software. For now we propose to use this - base class as a container for organizing data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - e.g. a geodesic (surface) mesh was instantiated as there are many - possibilities to do so. - - - - - Possibility to store details such as when primitives form a (specific) type - of mesh such as geodesic meshes. - - - - - - diff --git a/contributed_definitions/NXcg_roi.nxdl.xml b/contributed_definitions/NXcg_roi.nxdl.xml deleted file mode 100644 index 329c767c4a..0000000000 --- a/contributed_definitions/NXcg_roi.nxdl.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to - define explicitly the reference frame in which the primitives are - defined. - - - - Base class for a region-of-interest (ROI) bound by geometric primitives. - - So-called region-of-interest(s) (ROIs) are typically used to describe a - region in space (and time) where an observation is made or for which - a computer simulation is performed with given boundary conditions. - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron.nxdl.xml b/contributed_definitions/NXcg_tetrahedron.nxdl.xml deleted file mode 100644 index 95bf4e02dc..0000000000 --- a/contributed_definitions/NXcg_tetrahedron.nxdl.xml +++ /dev/null @@ -1,76 +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. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Combined storage of all primitives of all tetrahedra. - - - - - Individual storage of each tetrahedron. - - - - - Individual storage of each tetrahedron as a graph. - - - diff --git a/contributed_definitions/NXcg_triangle.nxdl.xml b/contributed_definitions/NXcg_triangle.nxdl.xml deleted file mode 100644 index d6c91451b9..0000000000 --- a/contributed_definitions/NXcg_triangle.nxdl.xml +++ /dev/null @@ -1,92 +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. - - - - Number of unique vertices in the triangle set. - - - - - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. - - - - - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. - - - - - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. - - - - - - - - - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. - - - - - - - diff --git a/contributed_definitions/NXcg_unit_normal.nxdl.xml b/contributed_definitions/NXcg_unit_normal.nxdl.xml deleted file mode 100644 index 5eaacd9e75..0000000000 --- a/contributed_definitions/NXcg_unit_normal.nxdl.xml +++ /dev/null @@ -1,75 +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. - - Store normal vector information as properties of primitives. - Use only only as a child of an instance of :ref:`NXcg_primitive` - so that this instance acts as the parent to define a context. - - - - Direction of each normal - a unit normal. - - - - - - - - - An indicator which details the orientation of each normal vector - in relation to its primitive, assuming the object is viewed - from a position outside the object. - - * 0 - undefined - * 1 - outer unit normal vector - * 2 - inner unit normal vector - - - - - - diff --git a/contributed_definitions/NXchemical_composition.nxdl.xml b/contributed_definitions/NXchemical_composition.nxdl.xml deleted file mode 100644 index 6ff3a16885..0000000000 --- a/contributed_definitions/NXchemical_composition.nxdl.xml +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - - 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. - - - - 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 which are of a particular type. - By contrast, weight_percent normalization factorizes in the - respective mass of the elements. Software libraries that work with units - (like pint in Python) are challenged by these differences as at.-% and - wt.-% are both fractional quantities. - - - - - - - - - Total based on which composition information is normalized. - - - - - - - - Instances names for groups should use the chemical symbol of - the element as it is defined in the periodic table. - - - - Count or weight which, when divided by total yields the composition - of this element, isotope, molecule, or ion. - - - - - - - - Composition value for the element/ion referred to under name. - Composition is reported either normalized for atomic or weight - percent. The field normalization should be used to communicate - this explicitly. Composition should be reported consistently - for all instances ELEMENT. - - - - - Magnitude of the standard deviation of the composition. - - - - diff --git a/contributed_definitions/NXcircuit.nxdl.xml b/contributed_definitions/NXcircuit.nxdl.xml deleted file mode 100644 index b24caaa429..0000000000 --- a/contributed_definitions/NXcircuit.nxdl.xml +++ /dev/null @@ -1,163 +0,0 @@ - - - - - - - Constant to be used in the definition: the number of channels of the - circuit board. - - - - Number of channels of the circuit board. - - - - - Base class for documenting circuit devices. - - Electronic circuits are hardware components that connect several electronic components to achieve - specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. - - - - Hardware where the circuit is implanted; includes information about the - hardware manufacturers and type (e.g. part number) - All the elements below may be single numbers of an array of values with length N_channel - describing multiple input and output channels. - - - - - List of components used in the circuit, e.g., resistors, capacitors, transistors or any - other complex components. - - - - - Description of how components are interconnected, including connection points - and wiring. - - - - - Details of the power source for the circuit, including voltage and current - ratings. - - - - - Type of signal (input signal) the circuit is designed to handle, e.g., analog, - digital, mixed-signal. - - - - - - The operating frequency of the circuit, see also bandwidth, which is possibly - but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth - amplifier at low, audio frequencies 1 - 20,000 Hz). - - - - - The bandwidth of the frequency response of the circuit. - - - - - - Input impedance of the circuit. - - - - - Output impedance of the circuit. - - - - - Gain of the circuit, if applicable, usually all instruments have a gain - which might be important or not. - - - - - Root-mean-square (RMS) noise level (in current or voltage) - in the circuit in voltage or current. - - - - - Operating temperature range of the circuit. - - - - - Calibration data for the circuit. - - - - - Offset value for current or voltage. - - - - - Number of output channels collected to this circuit. Most probably N_channel. - - - - - Type of output signal, e.g., voltage, current, digital. - - - - - Power consumption of the circuit per unit time. - - - - - Status indicators for the circuit, e.g., LEDs, display readouts. - - - - - Protection features built into the circuit, e.g., overvoltage protection, - thermal shutdown. - - - - - Updated rate for several processes using the input signal, e.g., History Graph, the circuit - uses for any such process. - - - - - The rate at which the signal changes when ramping from the starting - value. - - - diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml deleted file mode 100644 index 2ad203b8fc..0000000000 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,169 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of images taken, at least one. - - - - - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different conventions and - models for quantifying the aberration coefficients. - - Correctors in an electron microscope are composed of multiple lenses - and multipole stigmators. Their technical details are specific for the - technology partner as well as microscope. Most technical details are - proprietary knowledge. - - If one component corrects for multiple types of aberrations (like it is the case - reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this - design when using corrector and monochromator in an application definition: - - * Use :ref:`NXcorrector_cs` for spherical aberration - * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration - * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration - - - - - Was the corrector used? - - - - - Specific information about the alignment procedure. This is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberrations. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. Suggestions from the community are - welcome here for guiding an improvement of this base class. - - - - - - - - The exposure time of single tilt images. - - - - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - - - - Image(s) taken during the alignment procedure - - - - - Convention used for storing measured or estimated aberrations (for each or the final image) - via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. - - 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. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml deleted file mode 100644 index f9fdd53ff3..0000000000 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - Base class for reporting the description of a computer - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - 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_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index aaba9ee04b..0000000000 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,114 +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. - - - - - Base class for packing and unpacking booleans. - - This base class bookkeeps metadata to inform software about necessary modulo - operations to decode e.g. set membership of objects in sets which are encoded - as a packed array of boolean values. - - One use case is processing of object sets (e.g. point cloud data). If e.g. a - spatial filter has been applied to a set of points we may wish to store - document efficiently which points were analyzed. Array of boolean values - is one option to achieve this. A value is true if the point is included. - The resulting boolean array will be filled with true and false values - in a manner that is often arbitrary and in general case-dependent. - - Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one does not store - the boolean array but just lists the identifiers of the points taken. - - For example, if within a set of 1000 points only one point is included, it would - take (naively) 4000 bits to store the array but only 32 bits to store e.g. the - ID of the single point that is taken. 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 in that - they store compact representation of set memberships. - - This base class can deal with the situation when the number of objects - is not an integer multiple of the bit depth used for storing the states. - - - - Possibility to refer to which set this mask applies. - - If depends_on is not provided, it is assumed that the mask - applies to its direct parent. - - - - - 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 content of the mask. If padding is used, - padding bits have to be set to 0. - - - - - - - diff --git a/contributed_definitions/NXcs_memory.nxdl.xml b/contributed_definitions/NXcs_memory.nxdl.xml deleted file mode 100644 index e12ef91842..0000000000 --- a/contributed_definitions/NXcs_memory.nxdl.xml +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - Base class for reporting the description of the memory system of a computer. - - - - - Qualifier for the type of random access memory. - - - - - - - - - Total amount of data which the medium can hold. - - - - diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml deleted file mode 100644 index 3e30e741a4..0000000000 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,83 +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 this base class is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Physical approach or algorithm whereby random numbers are generated. - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device whose the state is unpredictable - (physically). Some use a strategy of mangling information from the system - clock. Also in this case the sequence is not reproducible without having - additional pieces of information. - - In most cases though so-called pseudo-random number generator (PRNG) - algorithms are used. These yield a deterministic sequence of practically - randomly appearing numbers. These algorithms differ in their quality in - how close the resulting sequences are random, i.e. sequentially - uncorrelated. 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. - - - - - Parameter of the PRNG controlling its initialization - and thus controlling the specific sequence generated. - - - - - Number of initial draws from the PRNG after its initialized with the seed. - These initial draws are typically discarded in an effort to equilibrate the - sequence. If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/contributed_definitions/NXcs_process.nxdl.xml b/contributed_definitions/NXcs_process.nxdl.xml deleted file mode 100644 index 60a43f7bb2..0000000000 --- a/contributed_definitions/NXcs_process.nxdl.xml +++ /dev/null @@ -1,52 +0,0 @@ - - - - - - Base class for reporting the description of processing units of a computer. - - Examples are e.g. (classical) processing units (CPUs), coprocessor, - graphic cards, accelerator processing units or a system of these. - - - - Typical examples for the granularization of processing units are: - - * A desktop computer with a single CPU; describe using one instance of NXcircuit. - * A dual-socket server; describe using two instances of NXcircuit. - * A server with two dual-socket server nodes; describe with four - instances of NXcircuit surplus a field that defines their level - in the hierarchy. - - - - General type of the processing unit - - - - - - - - - diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml deleted file mode 100644 index e7eb54a203..0000000000 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description for performance and profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - 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 and these are used usually by multiple users. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app) took. - A frequent idea is here to answer practical questions like how critical is the - effect on the workflow of the scientists, i.e. is the analysis possible in - a few seconds or would it take days if I were to run this analysis on a - comparable machine? - For this more qualitative performance monitoring, mainly the order of - magnitude is relevant, as well as how this was achieved using parallelization - (i.e. reporting the number of CPU and GPU resources used, the number of - processes and threads configured, and providing basic details about the computer). - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks; in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization, i.e. by software and hardware developers as well as for - tracking bugs. Specialized software exists which documents such performance - data in specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions for now. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - 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 demands a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field e.g. for apps which use e.g. MPI - (Message Passing Interface) parallelization is to communicate - how many processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - 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 how many nominal threads were used at runtime. - Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - 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 deleted file mode 100644 index 637b759a56..0000000000 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,98 +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 for a more precise record of the - wall-clock time. - - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - 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/NXcs_storage.nxdl.xml b/contributed_definitions/NXcs_storage.nxdl.xml deleted file mode 100644 index b173c3dde3..0000000000 --- a/contributed_definitions/NXcs_storage.nxdl.xml +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - Base class for reporting the description of the I/O of a computer. - - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml deleted file mode 100644 index 62762b8181..0000000000 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,238 +0,0 @@ - - - - - - Base class for a set of components providing a controllable electron beam. - - The idea behind defining NXebeam_column as an own base class vs. adding these - concepts in NXinstrument_em is that the electron beam generating component - might be worthwhile to use also in other types of experiments. - - - - Tech-partner, microscope-, and control-software-specific name of the - specific operation mode how the ebeam_column and its components are - controlled to achieve specific illumination conditions. - - In many cases the users of an instrument do not or can not be expected to know - all intricate spatiotemporal dynamics of their hardware. Instead, they rely on - assumptions that the instrument, its control software, and components work as - expected to focus on their research questions. - - For these cases, having a place for documenting the operation_mode is useful - in as much as at least some constraints on how the illumination conditions were - is documented. - - - - - A physical part of an electron or ion microscope from which - the particles that form the beam are emitted. - - The hardware for an electron source in an electron microscope - may contain several components which affect the beam path. - - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - - - - The potential difference between anode and cathode. - - This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. - - .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - - - - - Voltage which is used to create an electric field that draws particles from - the source. - - This concept is related to term `Extraction Voltage`_ of the EMglossary standard. - - .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which is released from the source. - - This concept is related to term `Emission Current`_ of the EMglossary standard. - - .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which flows through the source. - - This concept is related to term `Filament Current`_ of the EMglossary standard. - - .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - - - - - 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. - - - - - - How long has the source been in operation. - - - - - - - - - A component for blanking the beam or generating pulsed electron beams. - See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ - or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. - - - - - Device to improve energy resolution or chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Qualitative type of the component. - - - - - - - - - - - - - - Was the corrector used? - - - - - - Energy dispersion in e.g. µm/eV. - - - - - Corresponding voltage for that energy dispersion. - - - - - - - Component that reshapes an ellipse-shaped electron beam into a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - 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 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 users. - - - - - - Electron biprism as it is used e.g. for electron holography. - - - - - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ - * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ - - - - Qualitative type - - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the electron beam at a given location. - - :ref:`NXtransformations` should be used to specify the location - or the position at which details about the beam were probed. - - This concept is related to term `Electron Beam`_ of the EMglossary standard. - - .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - - - - diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml deleted file mode 100644 index 2721a77f0e..0000000000 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ /dev/null @@ -1,405 +0,0 @@ - - - - - - - - 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 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. - - - - - 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 specializes :ref:`NXoptical_spectroscopy` by - extending the terms and setting specific requirements. - - 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 - - - - - 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. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of ellipsometry. - - - - - - - - - - - - - Properties of the ellipsometry equipment. - - - - What type of ellipsometry was used? See Fujiwara Table 4.2. - - - - - - - - - - - - - - - - - - - If focusing probes (lenses) were used, please state if the data - were corrected for the window effects. - - - - - - - - - - - - - Were the recorded data corrected by the window effects of the - focusing probes (lenses)? - - - - - Specify the angular spread caused by the focusing probes. - - - - - - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - 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. - - - - - - - - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - - - - - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better - directly in the location of the sample positioner or temperature sensor. - - - - 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). - - - - - - - - :ref:`External link <Design-Links>` to the data field in 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. - - Ideally, the link uses the relative path with respect to the actual - NeXus file. - - - - - - 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. - - - - - - diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml deleted file mode 100644 index ab856fe413..0000000000 --- a/contributed_definitions/NXem.nxdl.xml +++ /dev/null @@ -1,1613 +0,0 @@ - - - - - - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive, general description for the - standardization of data and metadata collected using electron microscopy. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used to study electron-beam matter interactions, explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. - - - - - - - - - - The configuration of the software that was used to generate this NeXus file. - - - - A collection of all programs and libraries used to generate this NeXus file. - Ideally, this would enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific set - of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - Instances can also be used to document the modules and libraries that - are offered by the computational environment such as those parsed - from conda or python virtualenv environments. - - - - - - - - - A (globally) unique persistent identifier for referring to this experiment. - - - - - Alias (short name) which scientists can use to refer to this experiment. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the 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 - use this start_time field. - - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even using only start_time and end_time - may not be sufficient to infer how long the experiment took or for how long - data were acquired. To bookkeep more fine-grained timestamps over the - course of the experiment is possible with start_time and end_time fields - of respective :ref:`NXevent_data_em` instances. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - See docstring of the start_time field to see how to use the - start_time and end_time together. - - - - - - Collection of serialized resources associated with the experiment. - Examples of such resources are files which are formatted using proprietary - data models of technology partners as those generated by the control software - of the microscope during the instrument session. - - - - - - - - - Information about persons who performed or were involved in the microscope - session or simulation run. - - - - - - - Given (first) name and surname. - - - - - Name of the affiliation at the point in time when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address at the point in time when the experiment was performed. - - Writing the most permanently used email is recommended. - - - - - Telephone number at the point in time when the experiment was performed. - - - - - User role at the point in time when the experiment was performed. - - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. - - - - - - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. - Samples can be real or virtual ones as annotated via is_simulation. - - The suggested best practice is to call this group sample. In those cases when - multiple samples need to be grouped inside one entry, these SAMPLE groups - should be named using the prefix sample followed an index starting from 1, i.e. - (sample1, sample2). - - There are at least two strategies how to store (meta)data when one analyzes multiple - samples - not different ROIs on a single sample though - in one session. - - One strategy is to store each sample and its results under an own NXem/ENTRY. - This is one of the most frequent use cases as during most sessions typically only a - single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. - - If multiple samples are investigated storing each of them in their own ENTRY group eventually will - demand unnecessary duplication of instrument details. - - This can be avoided by using another strategy for storing samples and their results. - Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, - like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., - i.e. instances should use sample as a name prefix. - - In this case the collection of events should use identifier_sample to state clearly for which - of the samples loaded the (characterization) event was detected. - - This concept is related to term `Specimen`_ of the EMglossary standard. - - .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - - - - Qualifier whether the sample is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - - - - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes this sample from all others - and especially the predecessor/origin from where that sample was cut off. An example of cutting off - is a steel sheet that is the parent sample from which a small portion was wire-eroded that - represents the sample that was then prepared for characterization with an electron microscope. - - The terms sample and specimen are here considered as exact synonyms. - - This field must not be used for an alias for the sample name. Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to identifier_parent. - - - - - - Identifier of the sample from which the sample was cut off or the string *None*. - I.e. the parent to this sample. - - The purpose of this field is to support functionalities for tracking - sample provenance in a research data management system. - - - - - - 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 timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - identifier_parent. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for material that is sensitive to the environment such as specimens that were - charged with fast diffusing elements or short-lived radioactive tracers. - - Additional time stamps prior to preparation_date are better placed in resources which - describe but do not pollute the description here with prose. Resolving these - connected metadata is considered the responsibility of the research data management - system and not the a NeXus file. - - - - - Specimen name - - - - - 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 research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by identifier_parent or walk through eventually deeply nested groups in - individual data instances. - - - - - (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 typically 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 a - region-of-interest connected to individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details. - - - - - Discouraged free-text field to provide further detail. - - - - - - The conventions used when reporting crystal orientations. - We follow the best practices of the Material Science community - that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - The most frequently used convention in Materials Science is zxz, which is based on the work - of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished - from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. - - - - - - - - - - - - - - - - - - - - - - - - Location of the origin of the processing_reference_frame. - - It is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). - - - - - - - Location of the origin of the sample_reference_frame. - - It is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - The reference frame that is defined by a specific detector. - - - - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - - - - - - - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - - - - - - - - - - - - Details about the control program used for operating the microscope. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A spherical aberration corrector is a typical component in a transmission electron microscope. - Many instruments have only one, in this case the variadic suffix should be dropped. - If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, - corrector_cs2. - - - - Use specifically when there are multiple instances. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Descriptor for the aperture setting 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 users. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Descriptor for the aperture setting 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 users. - - - - - - - - - - - - - - - Operation mode of the detector as displayed by the control software. - - - - - - - - - - - - - - - - - - - - Nominal current of the heater. - - - - - Nominal voltage of the heater. - - - - - - - - - - - - - Documentation for a simulation of electron beam-matter interaction. - - - - The program with which the simulation was performed. - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - Configuration of the simulation - - - - - Results of the simulation - - - - - - - - - - - - - This concept is related to term `Region Of Interest`_ of the EMglossary standard. - - .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml deleted file mode 100644 index c8959b455d..0000000000 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,678 +0,0 @@ - - - - - - - - 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 plot orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of phase solutions - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Base class method-specific for Electron Backscatter Diffraction (EBSD). - - The general procedure of an EBSD experiment is as follows: - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance - and tilt the stage into diffraction conditions. - - Users then typically configure the microscope for collecting quality data. - The EBSD detector is pushed in (if retractable). Subsequently, they fine tune - the illumination and aberration corrector settings and select one or multiple ROIs - for the microscope to machine off automatically. They configure on-the-fly - indexing parameter and then typically start the measurement queue. - From this point onwards typically the microscope runs automatically. - - Diffraction pattern get collected until the queue finishes or gets interrupted by - either errors or arrival at the end of the users' allocated timeslot at the instrument. - - Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. - Once indexed, these patterns are often not stored. - - Results are stored in files, which afterwards are typically copied - automatically or manually for archival purposes to certain storage - locations for further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. - - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy exemplified here for electron backscatter diffraction (EBSD). - The base class solves two key documentation issues within the EBSD community: - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted - according to NXem_ebsd) stores the connection between the microscope session and - the key datasets which are considered typically results of the afore-mentioned - steps involved in an EBSD experiment. - - Different groups in NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed, and many more (meta)data. - - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every experiment or simulation using EBSD. - - Otherwise, results would be ripped out of their context like it is the current situation - with many traditional studies where EBSD data were indexed on-the-fly and shared - with the community only via sharing the strongly processed files with results in some - formatting but without communicating all conventions used or just relying on the assumptions - that colleagues likely know these conventions even though - multiple definitions are possible. - - NXem_ebsd 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) experiments - where a combination of repetitive removal of material from the surface layer to measure - otherwise the same region-of-interest at different depth increments. Material removal - can be achieved with mechanical, electron, or ion polishing, using manual steps or - automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By virtue of design, these methods are destructive - either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these images are indexed to process - a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint - also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. - - This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. - - .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 - - - - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions are not met, the user is required to explicitly state this. - - Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the - base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. - - - - Origin of the gnomonic_reference_frame. - - Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to - assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. - - - - - - - - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - Details about the definition of the pattern center as a special point in the - gnomonic_reference_frame. - - Typically the gnomonic space is embedded in the detector space. - Specifically, the XgYg plane is defined such that it is 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 - one effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height, though, is that these become degenerated - if the detector region-of-interest is square-shaped. This is why instead of referring to - width and height it is better to state explicitly which direction is considered positive - when measuring distances. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. - - - - From which border of the EBSP (in the detector reference frame) is the pattern - center's x-position (PCx) measured. - - - - - - - - - - - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - From which border of the EBSP (in the detector reference frame) is the pattern - center's y-position (PCy) measured. - - - - - - - - - - - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - - This group documents relevant details about the conditions and the - tools for measuring diffraction patterns with an electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interest using a discretization into square or hexagon tiles. - - - - Physical time since the beginning of a timestamp that is required to be - the same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set need 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, - 30 minutes, 6 hours, or 24 hours of annealing. - - - - Timestamp relative to which time was counted to aid - converting between time and timestamp. - - - - - - Path to an instance of :ref:`NXdata` where the measured patterns are stored. - - - - - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured patterns or input (already processed EBSD data). - - - - - - This group documents relevant details about the conditions and the tools - used for simulating diffraction patterns with some physical model. - - This group should be used if (e.g. instead of a measurement) the patterns - were simulated (possibly awaiting indexing). - - In many practical cases where patterns are analyzed on-the-fly and dictionary - indexing strategies used, so-called master pattern(s) are used to compare - measured or simulated patterns with the master patterns. - - - - Path to an instance of :ref:`NXimage` where the simulated patterns are stored. - - - - - Reference (e.g. path and filename) to an existent digital resource which - stores either the patterns or input (already processed EBSD data) that are - about to become processed further as described by this NXem_ebsd instance. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilt, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable, precise, and accurate scientific results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, standard specimens made from silicon or quartz crystals - in specific orientations are used for this purpose. - - Considering that a system used is already calibrated well-enough is much - more frequently the case in practice than that users perform the calibration - themselves (with above-mentioned standard specimens). - - 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 has been calibrated already. Consequently, users pick from - an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. - Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and how this setup in the GUI. - - 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' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` - solves in that all conventions can be specified explicitly. - - - - Path to an instance of :ref:`NXem` where calibration data are stored. - - - - - Reference to a digital resource where the calibration is stored. - - - - - - Indexing is a data processing step performed either after or while (aka on-the-fly) - the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSP. Common to them is the - computational step where simulated or theoretically assumed patterns - are compared with the measured ones. These latter patterns are referred - to via the measurement or simulation groups of this base class respectively. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - patterns are, and thus if no, one, or multiple so-called solutions were found. - - Assumed or simulated patterns are simulated using kinematical or dynamical - theory of electron diffraction delivering master patterns. - - The Hough transform, one of the most frequently used traditional method for indexing - EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods - find more widespread usage for indexing. - - - - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - - - - - Principal algorithm used for indexing. - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - Binning i.e. downsampling to each pattern. - - - - - Specific parameter relevant only for certain algorithms used. - - - - - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXunit_cell` in this group must - have the group name prefixed with phase. The identifier in the name is an - integer. Start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, the null phase also known - as notIndexed. - - - - Spacing between the crystallographic planes that are defined via ``miller``. - - - - - - - - Relative intensity for the computed diffraction intensity (signal) for the - plane. - - - - - - - - In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps - this field stores how many scan points of the map were identified as matching best - with this phase. - - - - - How many reflectors for crystallographic planes are distinguished. - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - - * 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 :ref:`NXunit_cell`. - - In another example users may have skipped some scan points (not indexed - them at all) or used differing numbers of phases for indexing different scan points. - - The cumulated of this array decodes how identifier_phase and matching_phase - 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), - identifier_phase has as many entries as scan points - and matching_phase has also as many entries as scan points. - - - - - - - - The array phases_per_scan_point details how the identifier_phase - and the matching_phase arrays have to be interpreted. - - For the example with a single phase identifier_phase 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 - required) that a pattern matches eventually (not equally well) sufficiently - significant with multiple patterns. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models. Having such field is especially relevant - for recent dictionary- or artificial intelligence-based indexing methods to communicate - the results in a model-agnostic way in combination with matching_phase. - - Depending on the phases_per_scan_point value, identifier_phase and - matching_phase arrays represent a collection of concatenated tuples. - These 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 phases_per_scan_point. - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array phases_per_scan_point has to be specified because it details - how the identifier_phase and the matching_phase arrays are interpreted. - See documentation of identifier_phase for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence_index, mean_angular_deviation, or other. - - - - - - - - - - - Calibrated center positions of each scan point - in the sample surface reference system. - - - - - - - - - Fraction of successfully indexed patterns with a phase - not the null-phase vs the number_of_scan_points. - - - - - Number of scan points in the original mapping. - - - - - - An overview of the entire ROI. - - - - Descriptor representing the image contrast. - - - - - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - Descriptor values - - - - - - Calibrated coordinate along the y-axis. - - - - - - - Label for the y axis - - - - - - Calibrated coordinate along the x-axis. - - - - - - - Label for the x axis - - - - - - diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml deleted file mode 100644 index 31d4beb20c..0000000000 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - - - Number of X-ray photon energy (bins) - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Number of IUPAC line names - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental - characterization requires typically a sequence of characterization and preparation of the - surface to expose new surface layer that can be characterized in the next acquisition. - In effect, the resulting three-dimensional elemental information mappings are truly the - result of a correlation and post-processing of several measurements which is the field - of correlative tomographic usage of electron microscopy. - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Accumulated intensity over all pixels of the region-of-interest. - - - - Accumulated counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - Comma-separated list of symbols for elements from the periodic table that have - been confirmed present by the here reported EDS analysis. - - This field can be used when creating instances of :ref:`NXpeak` is not desired. - However, a collection of instances of NXpeak with individual NXatom - can be used to add isotopic information and other relevant context. - - - - - Details about individual indexed peaks. - - - - - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - - - - - - - - Theoretical energy of the line according to IUPAC. - - - - - 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 grouped with the same peak. - - - - - - - - - - Individual element-specific EDS/EDX/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. - - These element-specific EDS maps are instances of :ref:`NXimage` - that should be named by the element from the atom_types field. - - When signal contributions from several peaks were decomposed - users should ideally use a respective number of NXpeak instances - to give further context about the individual signal contributions - are summarized and shown together, e.g. the combined signal - under the curve of carbon and oxygen. - - In this case specify the processing details use peak and weight. - - - - Discouraged free-text field to add additional information. - - - - - Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that - documents which elements and their specific lines are theoretically located within - the energy_range of the spectrum from which the EDS (element) map was computed. - - - - - Associated :math:`[e_{min}, e_{max}]` bounds of the energy - range for which spectrum counts were accumulated. - - - - - - - - - A list of :ref:`NXpeak` instance names whose X-ray quanta were - accumulated for each pixel to obtain an element-specific - EDS map. - - - - - - - - A list of weights by how much the intensity of each peak - contributes to the intensity of the EDS map. - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index f76b090dea..0000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - Details about computational steps how the zero-loss peak was threaded. - - - - The program with which the zero-loss peak correction was performed. - - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each peak in the spectrum considered to be of relevance. - - - - - NXspectrum specialized for EELS. - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml deleted file mode 100644 index 10c580be31..0000000000 --- a/contributed_definitions/NXem_img.nxdl.xml +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - Base class for method-specific generic imaging with electron microscopes. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe regions-of-interest (ROIs). Examples can be single point aka spot - measurements, 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. - - - - - Which imaging mode was used? - - - - - - - - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - - diff --git a/contributed_definitions/NXem_measurement.nxdl.xml b/contributed_definitions/NXem_measurement.nxdl.xml deleted file mode 100644 index 4648fe57ac..0000000000 --- a/contributed_definitions/NXem_measurement.nxdl.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - Base class for documenting a measurement with an electron microscope. - - - - diff --git a/contributed_definitions/NXem_simulation.nxdl.xml b/contributed_definitions/NXem_simulation.nxdl.xml deleted file mode 100644 index 6ec01a7965..0000000000 --- a/contributed_definitions/NXem_simulation.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - Base class for documenting a simulation of electron beam-matter interaction. - - - - - - diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml deleted file mode 100644 index d6c7f90e05..0000000000 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time. - - - - - Base class to store state and (meta)data of events over the course of an atom probe experiment. - - Having at least one instance for an instance of NXapm is recommended. - - This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs - of atom probe research. Against static and dynamic quantities are split to avoid a duplication - of information. Specifically, the time interval considered is the entire time - starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the pulse_id field. The point in time when each was issued - is specified via the combination of start_time and delta_time. - - Which temporal granularity is adequate depends on the situation and research question. - Using a model which enables a collection of events offers the most flexible way to cater for - both atom probe experiments or simulation. To monitor the course of an ion extraction experiment - (or simulation) it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event - identifier. - - As set and measured quantities typically change over time and we do not yet know during the - measurement which of the events have associated (molecular) ions that will end up in the - reconstructed volume, we must not document quantities as a function of the evaporation_id but - as a function of the (pulsing) identifier_event. - - Conceptually and technically NeXus currently stores tensorial information as arrays of values - (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores - a set of temperature values but that field when used somewhere is a concept. However, that - concept has no information at which point in time these temperatures were taken. - An existent functional relationship between the two concepts is not defined. - - However, a correct interpretation of the temperature values demands knowledge about what is - the independent quantity on which temperature depends on or according to which frequency - temperature values were sampled. - In NeXus there are two approaches which cope with such correlations: - One is :ref:`NXdata` where the attribute signal specifies the correlation. - The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against - (dependent signal) and independent quantities into an own group. - In many cases this additional grouping is not desired though. - - One naive solution typically employed is then to store the independent variable values via a second - vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). - However, there is no independent logical connection between these two concepts, i.e. temperature - and time_stamp. - - In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_id, - which is the independent variable vector against which eventually dozens of channels of data are logged. - Not only are these channels logged they should ideally also be self-descriptive in that these channels have - pulse_id as the independent variable but we do not wish to duplicate this information all the time but - reference it. - - Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the - symbol depends_on but this is easily to be confused with depends_on that is used for instances of - :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming - applications to understand that the here build correlations are conceptually different ones. - - This issue should be discussed further by the NeXus community. - - - - 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. - - - - - Delta time array which resolves for each pulse_id the time difference - between when that pulse was issued and start_time. - - In summary, using start_time, end_time, delta_time, pulse_id_offset, - and pulse_id exactly specifies the connection between when a pulse was - issued relative to start and absolute in UTC. - - - - - - - - Integer used to name the first pulse to know if there is an - offset of the identifiers to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - pulse_id_offset and cardinality. For example if identifier run from - -2 to 3 the value for pulse_id_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where pulse_id_offset is 1 and 0 respectively. - - - - - Identifier that contextualizes how the detector and pulser of an atom probe - instrument follows a sequence of pulses to trigger field evaporation. - - The pulse_id is used to associate thus an information about time - when quantities have been collected via sampling. - - In virtually all cases the pulser is a blackbox. Depending on how the - instrument is configured during a measurement the target - values and thus also the actual values may change. - - Maybe the first part of the experiment is run at a certain pulse fraction but thereafter - the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, pulse_id is then an equally - long vector which stores the set of events (e.g. pulsing events) when that value was - measured. - - This may cause several situations: In the case that e.g. the pulse_fraction is never changed - and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the pulse_id e.g. 0 to indicate that the pulse_fraction was set - at the beginning and it was maintained constant during the measurement. - If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a - vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of pulse_id are then [0, 99999] respectively. - - - - - - - diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml deleted file mode 100644 index c26a78a7e6..0000000000 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - Base class to store state and (meta)data of events for electron microscopy. - - Event-related (meta)data, typically measured datasets like images and spectra. - To avoid repetitively storing static instrument-related metadata, - the dynamic (meta)data that typically changes for each image and spectrum - is split from the static (meta)data. - - Which temporal granularity is adequate to log events depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - - Electron microscopes are dynamic. Scientists often report that microscopes - *perform differently* across sessions. That *they* perform differently from - one day or another. In some cases, root causes for performance differences - are unclear. Users of the instrument may consider such conditions impractical, - or *too poor*, and thus abort their session. Alternatively, users may try to - bring the microscope into a state where conditions are considered better - or of whatever high enough quality for starting or continuing the measurement. - - In all these use cases it is useful to have a mechanism whereby time-dependent - data of the instrument state can be stored and documented in an representation - that facilitates interoperability. This is the idea behind this base class. - - :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly - whatever is considered a time interval during which the instrument is - considered stable enough for allowing any working on tasks with it. - Examples of such tasks are the collecting of data (images and spectra) or - the calibrating the instrument or individual of its components. Users may wish to take - only a single scan or image and complete their session thereafter. - Alternatively, users are working for much longer time at the instrument, - perform recalibrations in between and take several scans (of different - ROIs on the specimen), or they explore the state of the microscope for - service or maintenance tasks. - - :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: - - * Firstly, via a header section whose purpose is to contextualize - and identify the event instance in time. - * Secondly, via a data and metadata section where individual data - collections can be stored in a standardized representation. - - We are aware of the fact that given the variety how an electron microscope - is used, there is a need for a flexible and adaptive documentation system. - At the same time we are also convinced though that just because one has - different requirements for some specific aspect under the umbrella of settings - to an electron microscope, this does not necessarily warrant that one has to - cook up an own data schema. - - Instead, the electron microscopy community should work towards reusing schema - components as frequently as possible. This will enable that there is at all - not only a value of harmonizing electron microscopy research content but also - there is a technical possibility to build services around such harmonized data. - - 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 a stack of spectra. Having to deal with instabilities is a common theme in - electron microscopy practice. Numerical protocols can be used during data - post-processing to correct for some of the instabilities. - A few exemplar references provide an overview on the subject: - - * `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 (digital twin), 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 and ions, or detector noise models. - This also warrants to document the time-dependent details of individual components - of the microscope via the here implemented class :ref:`NXevent_data_em`. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. - - If users wish 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. - - - - - Identifier of a specific state and setting of the microscope. - - - - - The name of the sample to resolve ambiguities. - - - - - 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 for which there is at the moment no other place. - - In the long run such free-text field description should be avoided as - it is difficult to machine-interpret. Instead, an enumeration should - be used. - - - - - - - diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml deleted file mode 100644 index 8515589d7c..0000000000 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - - Base class for a set of components equipping an instrument with FIB capabilities. - - Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped - with sufficient ion having sufficient momentum to remove material in a controlled - manner. - - The fact that an electron microscope with FIB capabilities achieves these functionalities - via a second component (aka the ion gun) that has its own relevant control circuits, - focusing lenses, and other components, warrants the definition of 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 flux - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and - entering the vacuum flight path. - - - - - To be defined more specifically. Community suggestions are welcome. - - - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - :ref:`NXtransformations` should be used to specify the location or position - at which details about the ion beam are probed. - - - - - diff --git a/contributed_definitions/NXimage.nxdl.xml b/contributed_definitions/NXimage.nxdl.xml deleted file mode 100644 index d627106a2d..0000000000 --- a/contributed_definitions/NXimage.nxdl.xml +++ /dev/null @@ -1,627 +0,0 @@ - - - - - - - - - Number of images in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slow dimension (k equivalent to z). - - - - - Number of image points along the fast dimension (j equivalent to y). - - - - - Number of image points along the fastest dimension (i equivalent to x). - - - - - Base class for reporting a set of images representing specializations of NXdata. - - The most commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Colloquially, an image is understood as a discretized representation of intensity distribution - detected or simulated for some ROI. When discretized with regular Euclidean tilings, the terms - pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal - or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. - For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually more appropriate when working with such tilings. - - Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). - - Point coordinates identify the location of the barycenter. - - For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal - (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. - Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations: - - * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ - * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - * `NFFT by the TU Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations - - Users are strongly advised to inspect carefully which specific conventions their library uses - to enable storing and modifying the implementation of their code such that the serialized - representations as they are detailed here for NeXus match. - - It is often the case that several images are combined using processing. In this case, - the number of images which are combined into collections is not necessarily the same - for each collection. The NXimage base class addresses this logical distinction - through the notation of indices_image and indices_group concepts. - That is indices_image are always counting from offset in increments of one - as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, indices_group are not required to be contiguous. - - - - Details how NXdata instance were processed from detector readings/raw data. - - - - Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` - instances in this :ref:`NXimage` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *context* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - Program used for processing. - - - - - - One-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - Real part of the image intensity per point. - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Two-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Three-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of one-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of two-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of three-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - diff --git a/contributed_definitions/NXinstrument_apm.nxdl.xml b/contributed_definitions/NXinstrument_apm.nxdl.xml deleted file mode 100644 index 65af1c93a4..0000000000 --- a/contributed_definitions/NXinstrument_apm.nxdl.xml +++ /dev/null @@ -1,392 +0,0 @@ - - - - - - - Base class to document an instrument used for atom probe microscopy. - - Inheriting from NXinstrument, this base class is designed to offer the same concepts about - instrument-centric metadata to be used in two places inside NXapm without demanding that - the application definition needs to define the concepts in two places as maintaining this is - prone to errors. This base class implements the key design idea behind the NXapm application - definition in that we would like to offer a design where all (meta)data which over the course - of a measurement remain static can be stored only once and without polluting the application - definition with another group with concepts that should be used for storing (meta)data about - the instrument during events that happen during the course of the measurement. - - This design was inspired by NXem and electron microscopy where typically the instrument is - used in sessions and dozens of logical sets of data are collected under not necessarily always - the same instrument conditions. We do not want to repeat therefore the static (meta)data, as - this is redundant storage by virtue of design. The typical example is an electron microscope - where hundreds of images are taken and all static instrument data stored with each image. - This makes sense in cases when the image is used as a digital artifact that is exchanged across - different software applications or research data management systems but as in NeXus there - is either all information bundled into one artifact or there is a coordinating master artifact - that references related artifacts there is no point to store hundreds of times that always the - same microscope with the same lens setup was used to collect these images. - - - - Which type of instrument. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Location of the lab or place where the instrument is installed. Using GEOREF is - preferred. - - - - - Device which reduces ToF differences of ions in ToF experiments. - - For atom probe the reflectron can be considered an energy compensation device. - Such a device can be realized technically for example with a Poschenrieder lens. - - Consult the following U.S. patents for further details: - - * 3863068 and 6740872 for the reflectron - * 8134119 for the curved reflectron - - - - Was the reflectron used? - - - - - The maximum voltage applied to the reflectron, relative to system ground. - - - - - - A counter electrode of the LEAP 6000 series atom probes. - - - - - - A local electrode guiding the ion flight path. - Also called counter or extraction electrode. - - - - Acceleration voltage - - - - - - - Detector for taking raw time-of-flight and ion/hit impact positions data. - - - - 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. - - - - - - - - CRunHeader.fMcpEfficiency - - - - - CRunHeader.fMeshEfficiency - - - - - - - Laser- and/or voltage-pulsing device to trigger ion removal. - - - - - - Detail whereby ion extraction is triggered methodologically. - - - - - - - - - - - Frequency with which the pulser fire(s). - - - - Path to pulse_id - - - - - - 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. - - - - Path to pulse_id - - - - - - - Pulsed voltage, in laser pulsing mode this field can be omitted. - - - - Path to pulse_id - - - - - - Absolute number of pulses starting from the beginning of the experiment. - - - - Path to pulse_id - - - - - - - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. Otherwise, the - standing voltage applied to the sample, relative to system ground. - - - - Path to pulse_id - - - - - - Atom probe microscopes use controlled laser, voltage, or a combination of - pulsing strategies to trigger ion extraction via exciting and eventual field evaporation - field emission of ion at the specimen surface. - - - - The wavelength of the radiation emitted by the source. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - Average energy of the laser at peak of each pulse. - - - - Path to pulse_id - - - - - - Details about specific positions along the laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the measurement - how the laser beam shines on the specimen, i.e. the mean vector - is parallel to the laser propagation direction. - - - - Path to pulse_id - - - - - - Track time-dependent settings over the course of the measurement - where the laser beam exits the focusing optics. - - - - Path to pulse_id - - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - Path to pulse_id in an instance of :ref:`NXevent_data_apm`. - - - - - - - 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. - - - - - - - - - CRunHeader.CAnalysis.fSpecimenTemperature - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - - - - - - - - - - CRunHeader.CLasHeader.fAnalysisPressure - - - - - - - - - - - - Free-text field for additional comments. - - - - - Relevant quantities during a measurement with a LEAP system as were - suggested by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. - - - - Parameter set typically in the GUI of the control software which - defines the rules and control loops whereby the pulser and other - components of the instrument are controlled during evaporation. - - - - - Control parameter set typically in the GUI relevant to assure that - the instrument internally controls its settings such to assure a - significant yet not too high ion influx on the detector to avoid - detection losses. - - - - diff --git a/contributed_definitions/NXinstrument_em.nxdl.xml b/contributed_definitions/NXinstrument_em.nxdl.xml deleted file mode 100644 index b5ade16b67..0000000000 --- a/contributed_definitions/NXinstrument_em.nxdl.xml +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - Base class for instrument-related details of a real or simulated electron microscope. - - For collecting data and experiments which are simulations of an electron - microscope (or such session) use the :ref:`NXem` application definition and - the :ref:`NXevent_data_em` groups it provides. - - This base class implements the concept of :ref:`NXem` whereby (meta)data are distinguished - whether these typically change during a session (dynamic) or not (static metadata). - This design allows to store e.g. hardware related concepts only once instead of demanding - that each image or spectrum from the session needs to be stored also with the static metadata. - - - - 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. - - - - - Different types of electron microscopes exist: - - * sem, a scanning electron microscope without focused-ion beam capabilities - * fib, a scanning electron microscope with focused-ion beam capabilities - irrespective whether these were used or not - * tem, a transmission electron microscope - - NXem is one joint data model that can be used to document research that is performed - with several of these types of microscopes (SEM, TEM, or FIB). The NXem data model - stresses that these types of instruments despite having several differences are still all - electron beamlines with which to probe electron and/or ion matter interaction and in fact - in practice have many similarities in how they are used, the components, they contain, etc. - - This field can be used in research data management systems for enabling a categorization - or tagging of experiments without having to analyze if groups like NXibeam_column are present - (which would indicate type is fib) or if certain lens configurations or instrument models are used - which suggests the microscope is a scanning (sem) or transmission electron microscope (tem): - - - - - - - - - - - - - - - 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. - - - - - - Stages in an electron microscope are multi-functional devices. - - Stages enable experimentalists the application of controlled external stimuli - on the specimen. Modern stages realize a hierarchy of components. - A multi-axial tilt rotation holder is a good example where the control of - each degree of freedom is technically implemented via providing instances - of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating - and positioning of the specimen. - - The physical process of mounting a specimen on a stage in practice often - comes with an own hierarchy of fixtures to bridge e.g. length scales technically. - An example from atom probe microscopy is that researchers may work - with wire samples which are clipped into a larger fixing unit to enable - careful specimen handling. Alternatively, a microtip is a silicon post - upon which e.g. an atom probe specimen is mounted. Multiple of such microtips - are then grouped into a microtip array to conveniently enable loading of multiple - specimens into the instrument with fewer operations. There are further scenarios - typically encountered related to mounting and locating specimens inside an - electron microscope, a few examples follow: - - * A nanoparticle on a copper grid. The copper grid is the holder. - This grid itself is fixed to a stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. A typical - example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Free-text field to give a term how that a stage_lab at this level of the - stage_lab hierarchy is commonly referred to. Examples could be stub, - puck, carousel, microtip, clip, holder, etc. - - - - - - The interpretation of this tilt1 value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - tilt is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - - - - Discouraged free-text field to provide details about how to interpret tilt1. - - - - - - The interpretation of this tilt2 value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - tilt is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - - - - Discouraged free-text field to provide details about how to interpret tilt2. - - - - - - The interpretation of this rotation value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - rotation is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - - - - Discouraged free-text field to provide details about how to interpret rotation. - - - - - - The interpretation of these position values can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - position values are defined explicitly using instances of :ref:`NXtransformations` - and respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - - - - - - - - - In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically - frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and - relocated portions of the specimen that have been cut off during site-specific lift-outs - and specimen preparation. - - - - - - - diff --git a/contributed_definitions/NXinteraction_volume_em.nxdl.xml b/contributed_definitions/NXinteraction_volume_em.nxdl.xml deleted file mode 100644 index c144734463..0000000000 --- a/contributed_definitions/NXinteraction_volume_em.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Base class to describe the volume of interaction for particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle-resolved sets of trajectories. - - Explicit or implicit descriptions of the geometry of this - interaction volume 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 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 flux through - an imaginary control surface (the iso-surface) 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>`_ - * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml deleted file mode 100644 index 2ea0b37c28..0000000000 --- a/contributed_definitions/NXion.nxdl.xml +++ /dev/null @@ -1,112 +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. - - - - - Base class for documenting the set of atoms of a (molecular) ion. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in id_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - - - - - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - - - - - - - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - - - - - - - diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml deleted file mode 100644 index 7a05016ab4..0000000000 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - 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, or vibropolishing. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Sequence index that logically arranges this step along a workflow. - - - - - - - - - - - - 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 on the machine, - 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 deleted file mode 100644 index 470133c20e..0000000000 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - 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/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml deleted file mode 100644 index 269dbad0e8..0000000000 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ /dev/null @@ -1,369 +0,0 @@ - - - - - - - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - From which file should the microstructure be instantiated. - - - - - - - - - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! - - - - - - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. - - - - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. - - - - - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - - - - - - - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. - - - - The simulation stops if the total number of grains - becomes smaller than this criterion. - - - - - The simulation stops if more iterations than this criterion have been computed. - - - - - - Configuration of numerical details of the solver. - - - - - Which type of convolution kernel and model is used. - - - - - - - - - - Constant to calibrate the real time scaling of the simulation. - - - - - - - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. - - - - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. - - - - - If true grid coarsement is active, otherwise it is not. - - - - - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. - - - - - - - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. - - - - - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - - - - - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - - - - - Mobility scaling factor :math:`c_2`. Typically 5. - - - - - Mobility scaling factor :math:`c_3`. Typically 9. - - - - - - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. - - - - Fundamental type of assumption if energies are considered isotropic or not. - - - - - - - - - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. - - - - - - - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. - - - - If true the curvature_driving_force is considered, otherwise it is not. - - - - - - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. - - - - If true the dislocation_driving_force is considered, otherwise it is not. - - - - - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. - - - - - - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. - - - - If true the magnetic_driving_force is considered, otherwise it is not. - - - - - - - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. - - - - Assumed triple junction drag. - - - - - - diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml deleted file mode 100644 index 7400e14636..0000000000 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ /dev/null @@ -1,293 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of summary statistic log entries. - - - - - Number of grains in the computer simulation. - - - - - Number of interfaces in the computer simulation. - - - - - Application definition for documenting results with GraGLeS. - - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - - - - - - - - Documentation of the spatiotemporal evolution - - - - - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - - - - Evolution of the recrystallized volume fraction over time. - - - - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - - - - - - - - Iteration or increment counter. - - - - - How many crystals are distinguished. - Crystals are listed irrespective of the phase to which these are assigned. - - - - - - - - - - Which type of stress. - - - - - - - - Applied external stress tensor on the ROI. - - - - - - - - - - - - Which type of strain. - - - - - Applied external strain tensor on the ROI. - - - - - - - - - - - - Which type of deformation gradient. - - - - - - - - Applied deformation gradient tensor on the ROI. - - - - - - - - - - - - Applied external magnetic field on the ROI. - - - - - - - - - - - - - Applied external electrical field on the ROI. - - - - - - - - - - - - - - - - Simulated temperature for this snapshot. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - One pair of indices_crystal values for each interface. - - - - - - - - - - Mobility times surface energy density of the interface normalized - to the maximum such product of the interface set. - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml deleted file mode 100644 index de75bd8274..0000000000 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ /dev/null @@ -1,242 +0,0 @@ - - - - - - - - How many texture components are distinguished, minimum is 1. - - - - - How many special texture components are distinguished if any. - - - - - Number of discrete orientations that are distributed across the grains. - - - - - Application definition for the configuration of the legacy (micro)structure generator - developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - The computational domain will be synthesized either as a square (for dimensionality = 2) - or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is - discretized into material points using either square pixel or cubic voxel as the tessellating - unit cells. - - - - Two-dimensional or three-dimensional simulation. - - - - - - - - - Target value for the number of material points per equivalent - discrete diameter of the arithmetic average sub-grain. - - - - - Assumed space group of the material. - - - - - - - - - - - Target value for the number of grains. The actual domain size and grid will be configured - based on the choices for discretization, number_of_grains, and shape of these grains. - - - - - Target value for the average number of sub-grains per grain. - - - - - - If available used to define the sequence of relative extent of grains along the y (first value) - and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, - the relative extent of the grains will be 1 one average along each axis (globulitic structure). - - - - - - - - - - In texture research component analyses set on the idea that properties - of grains different based on orientation with certain regions in orientation - space show similar trends like a different average dislocation density - or orientation_spread. - - - - The first entry is always the null model None which means that an orientation - is not categorized as a special component. Examples for special components are - Dillamore, Copper, Cube, Y, P and Q. - - - - - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - Disorientation angle below which an orientation is categorized as one of the - components. - - - - - - - - - Dislocations are modelled as Rayleigh-distributed mean-field density that - can differ between but is constant within grains and sub-grains. - - - - The minimum and the maximum dislocation density to distribute across grains. - - - - - - - - - The minimum and the maximum dislocation density to distribute across sub-grains. - - - - - - - - - - - The variance of the dislocation density distribution across the grains. - - - - - - - - The variance of the dislocation density distribution across the sub-grains. - - - - - - - - - Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation - of the (parent) grain and with optional Rayleigh-distributed scatter. - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - The variance of the disorientation of the sub-grain to their parent grain. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml deleted file mode 100644 index fb13ec2b9b..0000000000 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - - - Number of material points along the edge of the square- or cube-shaped domain. - - - - - Number of crystals. - - - - - Application definition for the results of the legacy (micro)structure generator developed - by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - Default plot showing the grid. - - - - - - - - Crystal identifier that was assigned to each material point. - - - - - - Material point barycenter coordinate along z direction. - - - - - - - Coordinate along z direction. - - - - - - Material point barycenter coordinate along y direction. - - - - - - - Coordinate along y direction. - - - - - - Material point barycenter coordinate along x direction. - - - - - - - Coordinate along x direction. - - - - - - - - - - - - - - - - - - - - - - - - - - True if the crystal is considered a sub-grain. - False if the crystal is considered a grain. - - - - - - - - Bunge-Euler angle orientation of each crystal. - - - - - - - - - Mean-field dislocation density as a measure of the stored elastic energy - content that is stored in the dislocation network of this grain and related - defects within each crystal. - - - - - - - - - diff --git a/contributed_definitions/NXoptical_lens.nxdl.xml b/contributed_definitions/NXoptical_lens.nxdl.xml deleted file mode 100644 index 084e5fc4ca..0000000000 --- a/contributed_definitions/NXoptical_lens.nxdl.xml +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - - - 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. - - - - Type of the lens (e.g. concave, convex etc.). - - - - - - - - - - - - - - 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_radius_front or curvature_radius_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. - - - - - The numerical aperture of the lens. - - - - - Magnification of the lens - - - diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml deleted file mode 100644 index d2dccd264d..0000000000 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ /dev/null @@ -1,1087 +0,0 @@ - - - - - - - - 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 measurements (1st dimension of measured data arrays). 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. - - - - - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free-text descriptions, it is recommended to use English, as this ensures - the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. - - - - - 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. - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise, the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. - - - - - Specify the type of the optical experiment. - - Use another term if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. - - - - - - - - - - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. - - - - - - - - - - - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. - - - - - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. - - - - - - - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. - - - - - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). - - - - - - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation - - - - - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties - - - - This can be used to describe properties of a photon beam. - A beam can be connected to components, via their - "inputs" and "outputs". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are actually measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) - - - - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). - - - - - - - - - - - - - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light source can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser - - - - - - - - - - - - - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. Note that the zero reference should be a direction vector for a - :ref:`reference_plane </NXbeam/TRANSFORMATIONS/reference_plane-field>` - normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. - This can be used if no definition of respective - coordinate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". - - - - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - - - - - - - - Raw data before calibration. - - - - - - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). - - - - - - - - - - - - - - - - - - - - - - - - - - - If available, name/ID/norm of the light source standard. - - - - - Details about the device information. - - - - - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - - - - - - - - - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible: - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam - - angle of in-plane sample rotation (direction along the sample's surface normal) - - An arbitrary reference frame can be defined by "reference_frames" - and used via "instrument/angle_sample_and_beam_TYPE" - - - - - - - - - Angle between sample incident beam and sample surface. - - - - - Angle between incident and detection beam - - - - - Sample tilt between sample normal, and the plane spanned by detection and - incident beam. - - - - - Inplane rotation of the sample, with rotation axis along sample normal. - - - - - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - - - - - 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. - These two directions span the plane of detection. - - - - - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - - - - - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - - - - - Set of transformations, describing the relative orientation of different - parts of the experiment (beams or sample). You may select one of the specified - angles for incident and detection beam or sample, and then use polar and azimuthal - angles to define the direction via spherical coordinates. - This allows consistent definition between different coordinate system. - You may refer to self defined coordinate system as well. - - - If "angle_reference_frame = beam centered", then this coordinate system is used: - McStas system (NeXus default) - (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - - i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and - the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` - is vertically oriented. - - If "angle_reference_frame = sample-normal centered", then this coordinate - system is used - z - math:`[0,0,1]` along sample surface normal - x - math:`[1,0,0]` defined by sample surface projected incident beam. - y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. - For this case, x may be ill defined, if the incident beam is perpendicular - to the sample surface. In this case, use the beam centered description. - - - - - - - - - - - Rotation about the y axis (polar rotation within the sample plane). - - - - - - - - - - - - - - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - - - - - - Rotation about the z axis (azimuthal rotation within the sample plane). - - - - - - - - - - - - - - - - - - - - - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - - - - - Optical components along the optical beam path. - - Every object which interacts or modifies optical beam properties, - may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - - - - This is the optical element used to focus or collect light. This may - be a generic lens or microcope objectives which are used for the - Raman scattering process. - - - - - - - - - - - - - - - - Polarization filter to prepare light to be measured or to be incident - on the sample. - Generic polarization filter properties may be implemented via NXfilter_pol - at a later stage. - - - - Physical principle of the polarization filter used to create a - defined incident or scattered light state. - - - - - - - - - - - Specific name or type of the polarizer used. - - Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... - - - - - - - Spectral filter used to modify properties of the scattered or incident light. - - - - Type of laser-line filter used to suppress the laser, if measurements - close to the laser-line are performed. - - - - Blocks shorter wavelengths and transmits longer wavelengths. - - - Blocks longer wavelengths and transmits shorter wavelengths. - - - Blocks a narrow wavelength band while transmitting others. - - - Reflects certain wavelength ranges instead of absorbing them. - - - Reduces light intensity uniformly across all wavelengths. - - - - - - Type of laser-line filter used to suppress the laser, if measurements - close to the laser-line are performed. - - - - - - - - - - - Properties of the spectral filter such as wavelength dependent transmission - or reflectivity. - - - - Which property is used to form the spectral properties of light, - i.e. transmission or reflection properties. - - - - - - - - - - - - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. - - - - - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. - - - - Specify the type of the sample stage. - - - - - - - - - - - - - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. - - - - - Description of relation of the beam with the sample. How does the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - This is redundant if a full orientation description is done via the - stage's "transformations" entry. - - - - - - - - - - - - - - - - - - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. - - - - - - - - - - - - - - - - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - - - - - - - - - - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - - - - 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. - - - - - Description of the software by persistent resource, where the program, - code, script etc. can be found. - - - - - - - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - - - - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - - - - - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - - - - - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - calibration_time. - - - - - - - - - - - - If calibration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - - - - - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. - - - - - - The overall resolution of the optical instrument. - - - - - - - - - - Minimum distinguishable wavelength separation of peaks in spectra. - - - - - - - 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. - - - - - Locally unique ID of the sample, used in the research institute or group. - - - - - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. - - - - - Free text description of the sample. - - - - - 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'. - - - - - 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 timestamp when - the measured specimen surface was actively prepared. - - - - - A set of activities that occurred to the sample prior to/during the experiment. - - - - - Sample temperature (either controlled or just measured). - - - - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. - - - - - - - - - - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - - - - - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - - - - - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. - - - - - - Arbitrary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperature description of the sample. - - - - Medium, in which the sample is placed. - - - - - - - - - - - - - - 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. - - - - - - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - 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. - - - - - If a thickness if given, please specify how this thickness was estimated or - determined. - - - - - 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. - - - - - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. - - - - - If the sample is grown or fixed on a substrate, specify this here by - a free text description. - - - - - - Here generic types of data may be saved. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plottable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata - - - - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - - - - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - - - - - - - - Calibrated wavelength axis. - - - - - - - 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. - - - - - - - diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml deleted file mode 100644 index dc4099fa82..0000000000 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,159 +0,0 @@ - - - - - - Base class for qualifying an electron optical system. - - - - Distance which is present between the specimen surface and the detector plane. - - This concept is related to term `Camera Length`_ of the EMglossary standard. - - .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - The defocus aberration constant (oftentimes referred to as c_1_0). - See respective details in :ref:`NXaberration` class instances. - - - - - The angle which is given by the semi-opening angle of the cone in a convergent - beam. - - This concept is related to term `Convergence Angle`_ of the EMglossary standard. - - .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Distance which is determined along the optical axis within the column from (1) the - lower end of the final optical element between the source and the specimen stage; - to (2) the point where the beam is focused. - - This concept is related to term `Working Distance`_ of the EMglossary standard. - - .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - - - - - Geometry of the cross-section formed when the primary beam shines onto the - specimen surface. - - - - - - Electrical current which arrives at the specimen. - - This concept is related to term `Probe Current`_ of the EMglossary standard. - - .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - - - - - Specify further details how incipient electron or ion dose was quantified - (using beam_current, probe_current). - - `Reference <https://doi.org/10.1017/S1551929522000840>`_ discusses - an approach for (electron) dose monitoring in an electron microscope. - - The unit of the nominal dose rate is e-/(angstrom^2*s). - - - - - Nominal dose rate. - - - - - In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated - on a helical path about the optical axis. This causes an image rotation whose strength - is affected by the magnification. - - Microscopes may be equipped with compensation methods (implemented in hardware - or software) that reduce but not necessarily eliminate this rotation. - - See `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ for details. - - - - - Distance which lies between the principal plane of the lens and the focal point - along the optical axis. - - This concept is related to term `Focal Length`_ of the EMglossary standard. - - .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - - - - - Details about an imaging setting used during acquisition to correct perspective - distortion when imaging a tilted surface or cross section. - - This concept is related to term `Tilt Correction`_ of the EMglossary standard. - - .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 - - - - - Details about a dynamic focus correction used. - - This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. - - .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 - - - - - Details about a workflow used to keep the specimen in focus by automatic means. - - This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. - - .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 - - - diff --git a/contributed_definitions/NXoptical_window.nxdl.xml b/contributed_definitions/NXoptical_window.nxdl.xml deleted file mode 100644 index ef008db2f3..0000000000 --- a/contributed_definitions/NXoptical_window.nxdl.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - - - - A window of a cryostat, heater, vacuum chamber or a simple glass slide. - - This describes cryostat windows and other possible influences for ellipsometry - measurements. - - 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). - - 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 measurements should be - considered as a separate experiment (with a separate NeXus file), and - the reference data shall be :ref:`linked <Design-Links>` in - ``reference_data_link``. - - 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. - - - - Was a window correction performed? If so, describe the window - correction procedure in ``window_correction/procedure``. - - - - - Type of effects due to this window on the measurement. - - - - - - - - - - - Group to describe any window correction - if none performed, then omit this - - - - 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_file``. - - - - - :ref:`External link <Design-Links>` to the data field in the NeXus file which describes - the reference data if a reference measurement for window correction - was performed. - - Ideally, the reference measurement was performed on on the same sample, - using the same conditions as for the actual measurement, with - and, if possible, without windows. It should have been conducted as close in time - to the actual measurement as possible. - - Ideally, the link uses the relative path with respect to the actual - NeXus file. - - - - - - The material of the window. - - - - - - - - - - - - - - - If you specified 'other' as material, describe here what it is. - - - - - Thickness of the window. - - - - - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - - - diff --git a/contributed_definitions/NXphase.nxdl.xml b/contributed_definitions/NXphase.nxdl.xml deleted file mode 100644 index 9b0609a61e..0000000000 --- a/contributed_definitions/NXphase.nxdl.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - Base class to describe a (thermodynamic) phase as a component of a material. - - Instances of phases can be crystalline. - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model (no sufficiently significant information available). - In other words, the phase_name is n/a aka notIndexed. - - The identifier_phase value should match with the integer suffix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if three phases were used e.g. 0, 1, and 2, three instances of - :ref:`NXphase` named phase0, phase1, and phase2 should be stored - in that HDF5 file. - - - - - Given name as an alias for identifying this phase. - - If the identifier_phase is 0 and one would like to use - the field name, the value should be n/a or notIndexed. - - - - - - - - Instance names should use microstructure as a prefix. - - - - - Instance names should use ipf as a prefix. - - - - - Instance names should use odf as a prefix. - - - - - Instance names should use pf as a prefix. - - - diff --git a/contributed_definitions/NXprogram.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml deleted file mode 100644 index bc906b23b9..0000000000 --- a/contributed_definitions/NXprogram.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Base class to describe a software tool or library. - - - - Given name of the program. Program can be a commercial one a script, - or a library or a library component. - - - - 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/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml deleted file mode 100644 index ef7fe55f13..0000000000 --- a/contributed_definitions/NXpump.nxdl.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - Device to reduce an atmosphere (real or simulated) to a controlled pressure. - - - - Principle type of the pump. - - - - - - - - - - diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml deleted file mode 100644 index 418e955847..0000000000 --- a/contributed_definitions/NXraman.nxdl.xml +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Number of scattering configurations used in the measurement. - It is 1 for only parallel polarization measurement, 2 for parallel and cross - polarization measurement or larger, if i.e. the incident and scattered photon - direction is varied. - - - - - An application definition for Raman spectroscopy experiments. - - This application definition supports a wide range of Raman spectroscopy experiments. - These may be as simple as acquiring a single Raman spectrum from spontaneous Raman - scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also - includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant - Raman scattering, and multidimensional Raman spectra collected under varying conditions - such as temperature, pressure, or electric field. - - The application definition comprises two main components: - - 1. Structures defined in NXoptical_spectroscopy: - * Instrument configuration and data calibration - * Sensors monitoring sample or beam conditions - - 2. Structures specified and extended in NXraman: - * Description of the experiment type - * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) - * Detailed description of beam properties and their interaction with the sample - * Sample-specific information - - Information on Raman spectroscopy are provided in: - - General - - * Lewis, Ian R.; Edwards, Howell G. M. - Handbook of Raman Spectroscopy - ISBN 0-8247-0557-2 - - Raman scattering selection rules - - * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. - Group Theory - Application to the Physics ofCondensed Matter - ISBN 3540328971 - - Semiconductors - - * Manuel Cardona - Light Scattering in Solids I - eBook ISBN: 978-3-540-37568-5 - DOI: https://doi.org/10.1007/978-3-540-37568-5 - - * Manuel Cardona, Gernot Güntherodt - Light Scattering in Solids II - eBook ISBN: 978-3-540-39075-6 - DOI: https://doi.org/10.1007/3-540-11380-0 - - * See as well other Books from the "Light Scattering in Solids" series: - III: Recent Results - IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects - V: Superlattices and Other Microstructures - VI: Recent Results, Including High-Tc Superconductivity - VII: Crystal-Field and Magnetic Excitations - VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons - IX: Novel Materials and Techniques - - Glasses, Liquids, Gasses, ... - - Review articles: - Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, - Surface-enhanced Raman scattering, Tip-enhanced Raman scattering - * https://doi.org/10.1186/s11671-019-3039-2 - - - - - An application definition for Raman spectroscopy. - - - - 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. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of Raman experiment. - - - - - - - - - - - - - - - - - - Metadata of the setup, its optical elements and physical properties which - defines the Raman measurement. - - - - Scattering configuration as defined by the porto notation by three - states, which are orthogonal to each other. Example: z(xx)z for - parallel polarized backscattering configuration. - - See: - https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman - - A(BC)D - - A = The propagation direction of the incident light (k_i) - B = The polarization direction of the incident light (E_i) - C = The polarization direction of the scattered light (E_s) - D = The propagation direction of the scattered light (k_s) - - An orthogonal base is assumed. - Linear polarized light is displayed by e.g. "x","y" or "z" - Unpolarized light is displayed by "." - For non-orthogonal vectors, use the attribute porto_notation_vectors. - - - - Scattering configuration as defined by the porto notation given by - respective vectors. - - Vectors in the porto notation are defined as for A, B, C, D above. - Linear light polarization is assumed. - - - - 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. - A has to be perpendicular to B and C perpendicular to D. - - - - - - - - - - Beam which is incident to the sample. - - - - - - diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml deleted file mode 100644 index ad6f289d72..0000000000 --- a/contributed_definitions/NXroi.nxdl.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - Base class to report on a region-of-interest of material analyzed or simulated. - - Do not confuse this base class with :ref:`NXregion`. - - - - - - - - - - - - diff --git a/contributed_definitions/NXrotations.nxdl.xml b/contributed_definitions/NXrotations.nxdl.xml deleted file mode 100644 index f931ac2591..0000000000 --- a/contributed_definitions/NXrotations.nxdl.xml +++ /dev/null @@ -1,244 +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 value tuples. - - - - - How many phases with usually different crystal and symmetry are distinguished. - - - - - - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ - * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ - * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ - * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ - - The concepts of mis- and disorientation are relevant when analyzing the - crystallography of interfaces. - - - - Reference to an instance of :ref:`NXcoordinate_system` which contextualizes - how the here reported parameterized quantities can be interpreted. - - - - - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided, point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field needs to encode two strings: - The first string is for phase A. The second string is for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - - - - - - - - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided, point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, have become obsolete thanks - to improvements in methods, software, and available computing power. - - Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. - - - - - - - - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. - - - - - - - - - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many possible - Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - - - - - - - - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. - - - - - - - - - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - The misorientation should not be confused with the disorientation, - as for the latter the angular argument is expected to be the minimal - obeying symmetries. - - - - - - - - - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - - - - - - - - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - - - - - - - - - - The set of disorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent disorientations - as defined by crystal_symmetry and sample_symmetry. - - - - - - - - - Disorientations angular argument (should not be signed, see - `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - - - - - - - - Disorientations axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. - - - - - - - diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml deleted file mode 100644 index af33885be3..0000000000 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - - number of components - - - - - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. - - - - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - Each component set can contain multiple components. - - - - - For description of a sub-component set. Can contain multiple components itself. - - - diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml deleted file mode 100644 index 111b1f94f6..0000000000 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - Scan box and coils which deflect a beam of charged particles in a controlled manner. - - The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, - which is not necessarily the same program as the one controlling other parts of the instrument. - - The scanbox directs the probe of charged particles (electrons, ions) - to controlled locations according to a scan scheme and plan. - - - - - Name of the typically tech-partner-specific term that specifies an - automated protocol which details how the components of the scan_box - and the instrument work together to achieve a controlled - scanning of the beam (over the sample surface). - - Oftentimes users do not need to or are not able to disentangle the intricate - details of the spatiotemporal dynamics of their instrument. Instead, often - they rely on the assumption that the instrument and its controlling programs - work as expected. The field scan_schema can be used to add some constraints - on how the beam was scanned over the surface. - - - - - - Time period during which the beam remains at one position. - - This concept is related to term `Dwell Time`_ of the EMglossary standard. - - .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - - - - - Time period during which the beam moves from the final position of one scan - line to the starting position of the subsequent scan line. - - This concept is related to term `Flyback Time`_ of the EMglossary standard. - - .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 - - - - - - Details about components which realize the deflection technically. - - This concept should be used for all those components that implement - the scanning of the beam, while components like beam blankers etc. should - use rather the NXdeflector concept of the NXebeam_column base class. - - - - diff --git a/contributed_definitions/NXspectrum.nxdl.xml b/contributed_definitions/NXspectrum.nxdl.xml deleted file mode 100644 index ac42594101..0000000000 --- a/contributed_definitions/NXspectrum.nxdl.xml +++ /dev/null @@ -1,550 +0,0 @@ - - - - - - - - - Number of spectra in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slower dimension (k equivalent to z). - - - - - Number of image points along the slow dimension (j equivalent to y). - - - - - Number of image points along the fast dimension (i equivalent to x). - - - - - Number of energy bins (always the fastest dimension). - - - - - Base class container for reporting a set of spectra. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Use stack for all other tilings. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` - instances in this :ref:`NXspectrum` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *context* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXspectrum` instance. - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - - - One spectrum for a point of a 0d ROI. Also known as spot measurement. - - - - Counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each point of a 1d ROI. - - - - Counts - - - - - - - - Counts - - - - - - Point coordinate along the fast dimension - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each scan point of 2d ROI. - - - - Counts - - - - - - - - - Counts - - - - - - Point coordinate along the slow dimension - - - - - - - Point coordinate along the slow dimension - - - - - - Point coordinate along the fast dimension - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for point of a 3d ROI. - - - - Counts - - - - - - - - - - Counts - - - - - - Point coordinate along the slower dimension - - - - - - - Point coordinate along the slower dimension - - - - - - Point coordinate along the slow dimension - - - - - - - Point coordinate along the slow dimension - - - - - - Point coordinate along the fast dimension - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_0d. - - - - Counts - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_2d. - - - - Counts - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slow dimension - - - - - - - Point coordinate along the slow dimension - - - - - - Point coordinate along the fast dimension - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_3d. - - - - Counts - - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slower dimension - - - - - - - Point coordinate along the slower dimension - - - - - - Point coordinate along the slow dimension - - - - - - - Point coordinate along the slow dimension - - - - - - Point coordinate along the fast dimension - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml deleted file mode 100644 index 919cbdcfff..0000000000 --- a/contributed_definitions/NXunit_cell.nxdl.xml +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - - - Dimensionality of the lattice. - - - - - Base class to describe structural aspects of an arrangement of - atoms or ions including a crystallographic unit cell. - - Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. - - - - Path to a reference frame in which the unit cell is defined - to resolve ambiguity in cases when e.g. a different reference frame - than the NeXus default reference frame (McStas) was chosen. - - - - - Dimensionality of the structure. - - - - - - - - - - Geometry of the unit cell quantified via parameters a, b, and c. - - - - - - - - Geometry of the unit cell quantified individually via parameter a. - - - - - Geometry of the unit cell quantified individually via parameter b. - - - - - Geometry of the unit cell quantified individually via parameter c. - - - - - Geometry of the unit cell quantified via parameters alpha, beta, and gamma. - - - - - - - - Geometry of the unit cell quantified individually via parameter alpha. - - - - - Geometry of the unit cell quantified individually via parameter beta. - - - - - Geometry of the unit cell quantified individually via parameter gamma. - - - - - Crystal system. - - For a crystal system in 2D space monoclinic is an exact synonym for oblique. - For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. - For a crystal system in 2D space tetragonal is an exact synonym for square. - - - - - - - - - - - - - - Laue group using International Table of Crystallography notation. - - - - - - Point group using International Table of Crystallography notation. - - - - - Space group from the International Table of Crystallography notation. - - - - - 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. - - - - - Area of the unit cell if dimensionality is 2. - - - - - Volume of the unit cell if dimensionality is 3. - - - - - diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml deleted file mode 100644 index 59c1ea8dbf..0000000000 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - - 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 or zero-order). - - - - - - - - - - - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4)). - - - - - - - - - - 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). In this case, also use type="achromatic". - - - - - - - - Wavelength resolved retardance of the waveplate. - - - - - Diameter of the waveplate (if the waveplate is circular). - - - - - 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 waveplate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - - - - Specify the material of the waveplate. If the device has a - coating it should be described in coating/coating_material. - - - - - Thickness of the waveplate substrate. - - - - - Complex index of refraction of the waveplate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. - - - - - - - - - - Is the waveplate 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. - - - \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml deleted file mode 100644 index 29b1343063..0000000000 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ /dev/null @@ -1,122 +0,0 @@ -category: base -doc: | - Quantified aberration coefficient in an aberration_model. - - For an introduction in the aberrations in electron microscopy - see `R. Dunin-Borkowski et al. `_ and - `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. - Conversion tables are also summarized by `Y. Liao `_ an introduction. -type: group -NXaberration(NXobject): - magnitude(NX_NUMBER): - unit: NX_ANY - doc: | - Magnitude of the aberration - magnitude_errors(NX_NUMBER): - unit: NX_ANY - doc: | - Uncertainty of the magnitude of the aberration - magnitude_errors_model(NX_CHAR): - doc: | - Free-text description how magnitude_errors was quantified - e.g. via the 95% confidence interval, variance, standard deviation, - using which algorithm or statistical model. - delta_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time elapsed since the last measurement. - angle(NX_NUMBER): - unit: NX_ANGLE - 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. - name(NX_CHAR): - doc: | - Given name to this aberration. - alias(NX_CHAR): - doc: | - Alias to name or refer to this specific type of aberration. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 56e233c76debb9af5eff7325e0624f51d50b71e6153718e5ecd01d30bae025b3 -# -# -# -# -# -# Quantified aberration coefficient in an aberration_model. -# -# For an introduction in the aberrations in electron microscopy -# see `R. Dunin-Borkowski et al. <https://doi.org/10.1017/9781316337455.022>`_ and -# `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. -# Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_ an introduction. -# -# -# -# Magnitude of the aberration -# -# -# -# -# Uncertainty of the magnitude of the aberration -# -# -# -# -# Free-text description how magnitude_errors was quantified -# e.g. via the 95% confidence interval, variance, standard deviation, -# using which algorithm or statistical model. -# -# -# -# -# Time elapsed since the last measurement. -# -# -# -# -# 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. -# -# -# -# -# Given name to this aberration. -# -# -# -# -# Alias to name or refer to this specific type of aberration. -# -# -# diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml deleted file mode 100644 index 4d9221e6db..0000000000 --- a/contributed_definitions/nyaml/NXapm.yaml +++ /dev/null @@ -1,2511 +0,0 @@ -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_ht: | - Number of hit qualities (hit types) distinguished. - n_dld: | - Number of delay-line wires of the detector. - n_bins: | - Number of bins used in the mass-to-charge-state-ratio spectrum. - p: | - Number of pulses collected in between start_time and end_time resolved by an - instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. - p_out: | - Number of pulses returned by the hit finding algorithm. - Neither necessarily equal to p nor to n. - n: | - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_id). This identifier must not be confused with - the pulse_id. Typically smaller than both p_out and p_out. -type: group -NXapm(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - definition(NX_CHAR): - \@version(NX_CHAR): - exists: optional - enumeration: [NXapm] - profiling(NXcs_profiling): - exists: optional - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) - which was used to generate this NeXus file instance. - - # command_line_call(NX_CHAR): - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - program(NX_CHAR): - \@version(NX_CHAR): - - # - run_number(NX_UINT): - exists: recommended - unit: NX_UNITLESS - - # cannot be made required as for simulations you do not have a run number! - doc: | - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually 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 (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored via NXnote in the - hit_finding algorithm section. - - 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. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. - experiment_alias(NX_CHAR): - exists: optional - doc: | - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - experiment_description(NX_CHAR): - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - # optional quantities do not need to be mentioned in an application definition because they can always be added - # if NXapm inherits from NXapm_base having this optional field does not need to be - # mentioned because optional nodes can always be added to a NeXus file instance without - # making it thereby non-compliant to the application definition - # the only difference is that if the consuming application wishes to demand to find that field - # it has to be specified in the application definition for the application definition to be a useful document of the contract - # which pieces of information a software expects to find and which not - # if you think about you being the consuming human (agent) also you would like to know - # if there is a run_number for the atom probe measurement from your colleague i.e. you - # effectively ask your colleague for that information while working off your imagined list of requirements - # the application definition here is nothing else then the documentation of this for a software - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping 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. For this - purpose the :ref:`NXevent_data_apm` instance should be used. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. - elapsed_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - doc: | - How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime - (NXcite): - exists: ['min', '0', 'max', 'unbounded'] - doi(NX_CHAR): - (NXnote): - exists: ['min', '0', 'max', 'unbounded'] - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - operation_mode(NX_CHAR): - doc: | - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * 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. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. `_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. - enumeration: - open_enum: true - items: [apt, fim, apt_fim] - (NXuser): - exists: recommended - identifierNAME(NX_CHAR): - nameType: partial - exists: recommended - \@type(NX_CHAR): - name(NX_CHAR): - exists: optional - 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 knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - 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. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. - identifierNAME(NX_CHAR): - nameType: partial - exists: recommended - is_simulation(NX_BOOLEAN): - doc: | - Qualifier whether the sample is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - alias(NX_CHAR): - doc: | - Given name/alias for the sample. - grain_diameter(NX_FLOAT): - exists: optional - unit: NX_LENGTH - 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. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. - grain_diameter_error(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Magnitude of the standard deviation of the grain_diameter. - - # schema for heat treatment - heat_treatment_temperature(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - 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 a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. - heat_treatment_temperature_error(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - Magnitude of the standard deviation of the heat_treatment_temperature. - heat_treatment_quenching_rate(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging aluminum samples left on the factory - parking lot on a hot summer day. - heat_treatment_quenching_rate_error(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - description(NX_CHAR): - exists: optional - chemical_composition(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(NX_CHAR): - ELEMENT(NXatom): - exists: ['min', '1', 'max', '118'] - nameType: any - chemical_symbol(NX_CHAR): - composition(NX_FLOAT): - composition_error(NX_FLOAT): - specimen(NXsample): - identifierNAME(NX_CHAR): - nameType: partial - exists: recommended - is_simulation(NX_BOOLEAN): - doc: | - Qualifier whether the specimen is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - alias(NX_CHAR): - exists: recommended - doc: | - Given name an alias. Better use identifierNAME and identifier_parent instead. - A single NXentry should be used only for the characterization of a single specimen. - identifier_parent(NX_CHAR): - exists: recommended - doc: | - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. - 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. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by identifier_parent. - - 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. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not - pollute the description here with prose. Resolving these connected - pieces of information is considered within the responsibility of the - research data management system. - atom_types(NX_CHAR): - doc: | - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by identifier_parent or walk through - eventually deeply nested groups in data instances. - description(NX_CHAR): - exists: optional - doc: | - Discouraged free-text field. - 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. - is_amorphous(NX_BOOLEAN): - exists: recommended - doc: | - Report if the specimen is amorphous. - initial_radius(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - doc: | - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. - shank_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - doc: | - Ideally measured otherwise best elaborated guess of the (initial) 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. - consistent_rotations(NXparameters): - exists: recommended - doc: | - The conventions used when reporting crystal orientations. - We follow the best practices of the Material Science community - that are defined in reference ``_. - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference ``_. - - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation according to convention 3 - of reference ``_. - enumeration: [passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference ``_. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference ``_. - enumeration: [rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference ``_. - enumeration: [p_plus_one, p_minus_one] - (NXcoordinate_system): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - A collection of coordinate systems. Several Euclidean - coordinate systems (CS) are used in the field of atom probe: - - * 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. - - 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 identifier interval. Typically, the set of - ion evaporation sequence identifiers 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. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. - origin(NX_CHAR): - alias(NX_CHAR): - type(NX_CHAR): - handedness(NX_CHAR): - x_direction(NX_CHAR): - y_direction(NX_CHAR): - z_direction(NX_CHAR): - measurement(NXapm_measurement): - exists: optional - doc: | - Base class for collecting a session with a real atom probe or field-ion microscope. - - Workflows used during experiments or simulations of atom probe and related field-evaporation - research should be documented in more detail and be better contextualized not only because of - ongoing developments and the tighter becoming connection between atom probe and other - methods for material characterization foremost electron microscopy see e.g.: - - * `T. Kelly et al. `_ - * `C. Fleischmann et al. `_ - * `W. Windl et al. `_ - * `C. Freysoldt et al. `_ - * `G. da Costa et al. `_ - - to mention but a few. - - To arrive at a design of base classes and an application definition that can be used - for both real and simulated atom probe experiments it is worthwhile to recall concepts that are - related to events and (molecular) ions: - - * Pulsing events which are used to trigger ion extraction events. - * Physical events and corresponding signal triggered by an ion hitting the detector. - Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. - * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input - and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are - worthwhile to be considered further and eventually included in the reconstructed volume. - * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually - selected (molecular) ions based on which an instance of a reconstruction is created. - * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values - and charge states of the (molecular) ions to substantiate that some of these ions can be considered - as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms - and subsequent peak labeling. In the field of atom probe this these peak identification methods - are known as ranging definitions. - - Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts - are well distinguished. However, the algorithms used to transform correlations between pulses and physical events - into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm. - - Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme - where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier - i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. - That is evaporation_id values take the role of an implicit time and course of the experiment given that - ion extraction physically is a sequential process. - - There is a number of research groups who build own instruments and share different aspects of their technical - specifications and approaches how they apply data processing e.g.: - - * `M. Monajem et al. `_ - * `P. Stender et al. `_ - * `I. Dimkou et al. `_ - - to name but a few. - - Despite some of these activities embrace practices of open-source development, they use essentially the same - workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface - software is used to explore and thus analyze reconstructed atom probe datasets. - - Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. - Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which - scientific conclusions about the characterized material volume are made. Also here a reconstruction is - point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model. - - By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all - the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. - Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. - We argue that this divide can be bridged with realizing the above-mentioned context and the realization that - similar concepts are used in both research realms with many concepts not only being similar but being exactly the same. - - A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed - datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment - and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting - a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as - (spatial) filtering and reconstruction algorithms. - - Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation - simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. - Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. - Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. - Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require - simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps - in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. - Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) - than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path - such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - status(NX_CHAR): - exists: recommended - doc: | - A statement whether the measurement was successful or failed prematurely. - enumeration: [success, failed] - quality(NX_CHAR): - exists: recommended - doc: | - CAnalysis.CResults.fQuality - instrument(NXinstrument_apm): - type(NX_CHAR): - exists: recommended - location(NX_CHAR): - exists: recommended - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - reflectron(NXcomponent): - exists: optional - applied(NX_BOOLEAN): - local_electrode(NXlens_em): - exists: recommended - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - ion_detector(NXdetector): - exists: recommended - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - pulser(NXcomponent): - exists: recommended - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - (NXsource): - exists: ['min', '0', 'max', '2'] - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - - # wavelength and pulse_energy as dynamic/volatile quantities stored in event data part - comment(NX_CHAR): - doc: | - Free text field for additional comments. - eventID(NXevent_data_apm): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - - # all these cannot be made required because for LEAP only stored in RHIT/HITS - # but for M-TAP and Oxcart these pieces of information are available. - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - - # delta_time(NX_NUMBER): - # pulse_id_offset(NX_INT): - # pulse_id(NX_INT): - instrument(NXinstrument_apm): - exists: recommended - reflectron(NXcomponent): - exists: recommended - voltage(NX_FLOAT): - - # decelerate_electrode(NXlens_em): - local_electrode(NXlens_em): - exists: recommended - voltage(NX_FLOAT): - - # ion_detector(NXdetector): - pulser(NXcomponent): - exists: recommended - pulse_mode(NX_CHAR): - pulse_frequency(NX_FLOAT): - pulse_fraction(NX_FLOAT): - pulse_voltage(NX_FLOAT): - exists: optional - dimensions: - rank: 1 - dim: (n,) - pulse_number(NX_UINT): - exists: optional - dimensions: - rank: 1 - dim: (n,) - standing_voltage(NX_FLOAT): - exists: optional - dimensions: - rank: 1 - dim: (n,) - (NXsource): - exists: ['min', '0', 'max', '2'] - wavelength(NX_FLOAT): - exists: recommended - unit: NX_WAVELENGTH - power(NX_FLOAT): - unit: NX_POWER - pulse_energy(NX_FLOAT): - dimensions: - rank: 1 - dim: (n,) - - # laser geometry at the moment has neither a worked out example - # nor any feedback from the community despite the work from B. Gault - # on laser atom probe was granted a Leibnitz award - stage(NXmanipulator): - temperature_sensor(NXsensor): - measurement(NX_CHAR): - value(NX_FLOAT): - analysis_chamber(NXcomponent): - pressure_sensor(NXsensor): - measurement(NX_CHAR): - value(NX_FLOAT): - control(NXparameters): - exists: recommended - evaporation_control(NX_CHAR): - target_detection_rate(NX_NUMBER): - simulation(NXapm_simulation): - exists: optional - doc: | - Simulation of ion extraction from matter via laser and/or voltage pulsing. - - # future possibility to reuse concepts from NXinstrument_apm again without - # the need for defining them again - atom_probe(NXroi): - exists: recommended - doc: | - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. - - # earlier comments here https://github.com/FAIRmat-NFDI/nexus_definitions/commit/a8602870f13f04b8befc902efb345afe650d8dd3 - initial_specimen(NXimage): - exists: recommended - doc: | - SEM or TEM image of the initial specimen (ideally taken prior data acquisition). - image_2d(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - real(NX_NUMBER): - axis_j(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - - # could use a stack_3d(NXdata) to record time series of specimen shape evolution - raw_data(NXprocess): - exists: recommended - doc: | - For almost atom probe instruments (meta)data about raw data follow proprietary semantics. - Therefore, this group can currently be used only to point to these digital artifacts - in an effort to document all step of an analysis workflow. - - The physical quantities measured in an atom probe experiment are time-of-flight and - tuples of arrival_time_pairs as a function of the event chain on the pulser. - From these tuples hits are computed in a process called hit_finding. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - - # point at least to the proprietary artifact - source(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # technical details of data the ion_detector collects - number_of_dld_wires(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - The number of wires in the detector. - enumeration: [1, 2, 3] - dld_wire_names(NX_CHAR): - exists: optional - doc: | - Alias tuple (begin, end) of each DLD wire of the detector. - Order follows arrival_time_pairs. - dimensions: - rank: 2 - dim: (n_dld, 2) - arrival_time_pairs(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - dimensions: - rank: 3 - dim: (p, n_dld, 2) - hit_finding(NXprocess): - exists: recommended - doc: | - Configuration of and results obtained from a hit finding algorithm. - - # we careful how we go about doing this here, we recommended to make some details of the hit_finding - # algorithm open namely the input and the output what the black box then does by AMETEK/Cameca - # does not have to be exposed (although this clearly is against FAIR principles but the scientific community - # is does not have the authority to decide which portions of proprietary code have to be public - # we can only make recommendations - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - - # config of the hit_finding algorithm - config(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # results of the hit_finding algorithm - hit_positions(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - doc: | - Evaluated ion impact coordinates on the detector. - Use the depends_on field to specify which reference - frame the positions are defined. - dimensions: - rank: 2 - dim: (p_out, 2) - \@depends_on(NX_CHAR): - doc: | - Defines in which reference frame the positions are defined. - total_event_golden(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - CRunHeader.fTotalEventGolden - total_event_incomplete(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - CRunHeader.fTotalEventIncomplete - total_event_multiple(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - CRunHeader.fTotalEventMultiple - total_event_partial(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - CRunHeader.fTotalEventPartials - total_event_record(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - CRunHeader.fTotalEventRecords - hit_quality_type(NX_CHAR): - exists: optional - doc: | - Hit quality is an integer that specifies which category/type a hit was assigned to. - This field lists the human-readable, possibly though proprietary types distinguished. - The indices of this array are used in hit_quality to encode hit_quality for each - pulse in a more efficient way than by repeating the string that is used for each - type as it is provided in this field. - - As an example assume two types golden and partial are distinguished. - If hit_quality_type stores the array "golden", "partial", the index 0 - in hit_quality identifies all those pulses of category golden, - while the index 1 in hit_quality identifies all of category partial. - dimensions: - rank: 1 - dim: (n_ht,) - hit_quality(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Hit quality identifier for each pulse. - Identifier have to be within hit_quality. - dimensions: - rank: 1 - dim: (p_out,) - hit_multiplicity(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - This processing yields for each ion with how many others it evaporated - if these were collected on the same pulse. Extraction of multiple ions - on one pulse on different or even the same pixel of the detector are possible. - - Multiplicity must not be confused with how many atoms of the same element - a molecular ion contains. - dimensions: - rank: 1 - dim: (p_out,) - - # the following two quantities are relicts from ePOS files used to give some - # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically - # used only in the context to learn about the multiplicity of an ion. - # pulses_since_last_ion(NX_UINT): - # dim: (n,) - # pulse_id(NX_INT): - # dim: (n,) - # at this point the original set of events p has been filtered down to p_out - hit_spatial_filtering(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - source(NXnote): - exists: optional - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - evaporation_id_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to name the first pulse to know if there is an - offset of the evaporation_id to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - evaporation_id_offset and cardinality. For example if identifier run from - -2 to 3 the value for evaporation_id_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where evaporation_id_offset is 1 and 0 respectively. - evaporation_id(NX_INT): - unit: NX_UNITLESS - doc: | - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. - dimensions: - rank: 1 - dim: (n,) - hit_filter(NXcs_filter_boolean_mask): - exists: recommended - - # use NXcs_filter needs conditionally an instance of concept ../../hit_finding - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_INT): - - # at this point the set of events p_out has been filtered down to n - voltage_and_bowl(NXprocess): - exists: recommended - doc: | - Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. - - The voltage-and-bowl correction is a data post-processing step to correct ion impact - positions for flight path differences, detector bias, and nonlinearities. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - source(NXnote): - exists: optional - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # currently cannot be made required proprietary hardware and semantics - raw_tof(NX_FLOAT): - exists: recommended - doc: | - Raw time-of-flight data without corrections. - dimensions: - rank: 1 - dim: (n,) - - # result - tof_zero_estimate(NX_FLOAT): - exists: optional - unit: NX_TIME - doc: | - The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate - calibrated_tof(NX_FLOAT): - exists: recommended - doc: | - Calibrated time-of-flight. - dimensions: - rank: 1 - dim: (n,) - mass_to_charge_conversion(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - source(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - mass_to_charge(NX_FLOAT): - dimensions: - rank: 1 - dim: (n,) - reconstruction(NXapm_reconstruction): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - config(NXnote): - exists: recommended - doc: | - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - results(NXnote): - exists: recommended - doc: | - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # config/input - parameter(NX_CHAR): - exists: recommended - protocol_name(NX_CHAR): - exists: recommended - crystallographic_calibration(NX_CHAR): - exists: recommended - field_of_view(NX_FLOAT): - exists: recommended - reconstructed_positions(NX_FLOAT): - dimensions: - rank: 2 - dim: (n, 3) - naive_discretization(NXprocess): - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - - # results - (NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - dimensions: - rank: 3 - dim: (n_z, n_y, n_x) - axis_z(NX_FLOAT): - dimensions: - rank: 1 - dim: (n_z,) - \@long_name(NX_CHAR): - axis_y(NX_FLOAT): - dimensions: - rank: 1 - dim: (n_y,) - \@long_name(NX_CHAR): - axis_x(NX_FLOAT): - dimensions: - rank: 1 - dim: (n_x,) - \@long_name(NX_CHAR): - ranging(NXapm_ranging): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - definitions(NXnote): - exists: recommended - doc: | - The respective ranging definitions file RNG/RRNG/ENV/HDF5. - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - mass_to_charge_distribution(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - min_incr_max(NX_FLOAT): - mass_spectrum(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - - # \@long_name(NX_CHAR): - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_bins,) - \@long_name(NX_CHAR): - axis_mass_to_charge(NX_FLOAT): - dimensions: - rank: 1 - dim: (n_bins,) - \@long_name(NX_CHAR): - background_quantification(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - background(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. - mrp_value(NX_FLOAT): - exists: recommended - unit: NX_DIMENSIONLESS - doc: | - MRP, mass-resolving power, `D. Larson et al. - `_ (p282, Eqs. D.7 and D.8). - mrp_mass_to_charge(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - MRP, at which mrp_value was specified. - - # TODO add description of background models and fit like in XPS - peak_search(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - (NXpeak): - exists: ['min', '0', 'max', 'unbounded'] - label(NX_CHAR): - exists: recommended - description(NX_CHAR): - category(NX_CHAR): - exists: recommended - doc: | - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) `_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` - enumeration: [0, 1, 2, 3, 4, 5] - position(NX_NUMBER): - - # peak deconvolution(NXprocess): - peak_identification(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - number_of_ion_types(NX_UINT): - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - ionID(NXion): - nameType: partial - exists: ['min', '1', 'max', '256'] - nuclide_hash(NX_UINT): - charge_state(NX_INT): - charge_state_analysis(NXapm_charge_state_analysis): - exists: optional - - # config - nuclides(NX_UINT): - mass_to_charge_range(NX_FLOAT): - min_half_life(NX_FLOAT): - min_abundance(NX_FLOAT): - min_abundance_product(NX_FLOAT): - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - - # results - charge_state(NX_INT): - nuclide_hash(NX_UINT): - mass(NX_FLOAT): - natural_abundance_product(NX_FLOAT): - shortest_half_life(NX_FLOAT): - mass_to_charge_range(NX_FLOAT): - nuclide_list(NX_UINT): - exists: recommended - name(NX_CHAR): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 50f616708b4d630624292cca62af60e5b55c1419688a32aff4c23873957cb138 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of hit qualities (hit types) distinguished. -# -# -# -# -# Number of delay-line wires of the detector. -# -# -# -# -# Number of bins used in the mass-to-charge-state-ratio spectrum. -# -# -# -# -# Number of pulses collected in between start_time and end_time resolved by an -# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of -# ions included in the reconstructed volume if the application definition is used -# to store results of an already reconstructed datasets. -# -# -# -# -# Number of pulses returned by the hit finding algorithm. -# Neither necessarily equal to p nor to n. -# -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# from which an instance of a reconstructed volume has been generated. -# These ions get new identifier assigned in the process (the so-called -# evaporation_id). This identifier must not be confused with -# the pulse_id. Typically smaller than both p_out and p_out. -# -# -# -# -# Application definition for atom probe and field ion microscopy experiments. -# -# -# -# -# -# -# -# -# -# -# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) -# which was used to generate this NeXus file instance. -# -# -# -# -# A collection of all programs and libraries which are considered relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# -# -# -# -# -# -# -# -# -# The identifier whereby the experiment is referred to in the control software. -# This is neither the specimen_name nor the experiment_identifier. For -# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the -# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. -# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, -# or the instruments at GPM in Rouen, use the identifier which matches -# best conceptually 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 (provided these -# RHIT or HITS files respectively are stored alongside a data artifact). -# With NXapm the RHIT or HITS can be stored via NXnote in the -# hit_finding algorithm section. -# -# 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. Such interrupted runs -# should be stored as individual :ref:`NXentry` instances in one NeXus file. -# -# -# -# -# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. -# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. -# -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the atom probe session started. If the exact duration of -# the measurement is not relevant start_time only should be used. -# -# Often though it is useful to specify both start_time and end_time to -# capture more detailed bookkeeping 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. For this -# purpose the :ref:`NXevent_data_apm` instance should be used. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the atom probe session ended. -# -# -# -# -# How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime -# -# -# -# -# -# -# -# -# -# -# -# -# -# What type of atom probe experiment is performed? This field is meant to -# inform research data management systems to allow filtering: -# -# * apt are experiments where the analysis_chamber has no imaging gas. -# experiment with LEAP instruments are typically performed such. -# * 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. -# few experiments of this type have been performed as this can be detrimental -# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). -# * other should be used in combination with the user specifying details -# in the experiment_documentation field. -# -# If NXapm is used for storing details about a simulation use other for now. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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 knowledge they have gained about the sample. -# There are cases where the specimen is machined further or exposed to -# external stimuli during the experiment. In this case, these details should -# not be stored under sample but suggestions should be made -# how this application definition can be improved. -# -# 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. For this specific application definitions/schemas can be -# used which are then arranged and documented with a description of the -# workflow so that actionable graphs become instantiatable. -# -# -# -# -# Qualifier whether the sample is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# Given name/alias for the sample. -# -# -# -# -# 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. -# -# In atom probe it is possible that the specimen may contain a few -# crystals only. In this case the grain_diameter is not a reliable -# descriptor. Reporting a grain size may be useful though as it allows -# judging if specific features are expected to be found in the -# detector hit map. -# -# -# -# -# Magnitude of the standard deviation of 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 a documentation of the annealing -# treatment as a function of time is available one should better -# rely on this information and have it stored alongside the NeXus file. -# -# -# -# -# Magnitude of the standard deviation of the heat_treatment_temperature. -# -# -# -# -# Rate of the last quenching step. Knowledge about this value can give -# an idea how the sample was heat treated. However, there are many -# situations where one can imagine that the scalar value for just the -# quenching rate is insufficient. -# -# An example is when the sample was left in the furnace after the -# furnace was switched off. In this case the sample cools down with -# a specific rate of how this furnace cools down in the lab. -# Processes which in practice are often not documented. -# -# This can be problematic though because when the furnace door was left open -# or the ambient temperature in the lab changed, i.e. for a series of -# experiments where one is conducted on a hot summer day and the next -# during winter this can have an effect on the evolution of the microstructure. -# There are many cases where this has been reported to be an QA issue in industry, -# e.g. think about aging aluminum samples left on the factory -# parking lot on a hot summer day. -# -# -# -# -# Magnitude of the 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Qualifier whether the specimen is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# Given name an alias. Better use identifierNAME and identifier_parent instead. -# A single NXentry should be used only for the characterization of a single specimen. -# -# -# -# -# Identifier of the sample from which the specimen was cut or the string -# n/a. The purpose of this field is to support functionalities for -# tracking sample provenance via a research data management system. -# -# -# -# -# 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. Ideally, this -# matches the last timestamp that is mentioned in the digital resource -# pointed to by identifier_parent. -# -# 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. Additional time stamps prior to preparation_date -# should better be placed in resources which describe but which do not -# pollute the description here with prose. Resolving these connected -# pieces of information is considered within the responsibility of the -# research data management system. -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources pointed to by identifier_parent or walk through -# eventually deeply nested groups in data instances. -# -# -# -# -# Discouraged free-text field. -# -# -# -# -# Report if the specimen is polycrystalline, in which case it -# contains a grain or phase boundary, or if the specimen is a -# single crystal. -# -# -# -# -# Report if the specimen is amorphous. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the initial radius of the -# specimen. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the (initial) 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. -# -# -# -# -# -# The conventions used when reporting crystal orientations. -# We follow the best practices of the Material Science community -# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin. -# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parametrizations/representations according -# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# -# A collection of coordinate systems. Several Euclidean -# coordinate systems (CS) are used in the field of atom probe: -# -# * 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. -# -# 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 identifier interval. Typically, the set of -# ion evaporation sequence identifiers 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. -# -# To avoid these ambiguities, instances of :ref:`NXtransformations` should be used. -# -# -# -# -# -# -# -# -# -# -# -# Base class for collecting a session with a real atom probe or field-ion microscope. -# -# Workflows used during experiments or simulations of atom probe and related field-evaporation -# research should be documented in more detail and be better contextualized not only because of -# ongoing developments and the tighter becoming connection between atom probe and other -# methods for material characterization foremost electron microscopy see e.g.: -# -# * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ -# * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_ -# * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ -# * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ -# * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_ -# -# to mention but a few. -# -# To arrive at a design of base classes and an application definition that can be used -# for both real and simulated atom probe experiments it is worthwhile to recall concepts that are -# related to events and (molecular) ions: -# -# * Pulsing events which are used to trigger ion extraction events. -# * Physical events and corresponding signal triggered by an ion hitting the detector. -# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. -# * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input -# and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are -# worthwhile to be considered further and eventually included in the reconstructed volume. -# * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually -# selected (molecular) ions based on which an instance of a reconstruction is created. -# * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values -# and charge states of the (molecular) ions to substantiate that some of these ions can be considered -# as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms -# and subsequent peak labeling. In the field of atom probe this these peak identification methods -# are known as ranging definitions. -# -# Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts -# are well distinguished. However, the algorithms used to transform correlations between pulses and physical events -# into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm. -# -# Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme -# where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier -# i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. -# That is evaporation_id values take the role of an implicit time and course of the experiment given that -# ion extraction physically is a sequential process. -# -# There is a number of research groups who build own instruments and share different aspects of their technical -# specifications and approaches how they apply data processing e.g.: -# -# * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_ -# * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ -# * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ -# -# to name but a few. -# -# Despite some of these activities embrace practices of open-source development, they use essentially the same -# workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface -# software is used to explore and thus analyze reconstructed atom probe datasets. -# -# Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. -# Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which -# scientific conclusions about the characterized material volume are made. Also here a reconstruction is -# point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model. -# -# By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all -# the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. -# Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. -# We argue that this divide can be bridged with realizing the above-mentioned context and the realization that -# similar concepts are used in both research realms with many concepts not only being similar but being exactly the same. -# -# A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed -# datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment -# and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting -# a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as -# (spatial) filtering and reconstruction algorithms. -# -# Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation -# simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. -# Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. -# Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. -# Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require -# simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps -# in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. -# Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) -# than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path -# such as local electrodes or physical obstacles and electric fields (controlled or stray fields). -# -# -# -# A statement whether the measurement was successful or failed prematurely. -# -# -# -# -# -# -# -# -# CAnalysis.CResults.fQuality -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Free text field for additional comments. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Simulation of ion extraction from matter via laser and/or voltage pulsing. -# -# -# -# -# -# A region-of-interest analyzed either during or after the session for which -# specific processed data of the measured or simulated data are available. -# -# -# -# -# SEM or TEM image of the initial specimen (ideally taken prior data acquisition). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For almost atom probe instruments (meta)data about raw data follow proprietary semantics. -# Therefore, this group can currently be used only to point to these digital artifacts -# in an effort to document all step of an analysis workflow. -# -# The physical quantities measured in an atom probe experiment are time-of-flight and -# tuples of arrival_time_pairs as a function of the event chain on the pulser. -# From these tuples hits are computed in a process called hit_finding. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The number of wires in the detector. -# -# -# -# -# -# -# -# -# -# Alias tuple (begin, end) of each DLD wire of the detector. -# Order follows arrival_time_pairs. -# -# -# -# -# -# -# -# -# Raw readings from the analog-to-digital-converter -# timing circuits of the detector wires. -# -# -# -# -# -# -# -# -# -# -# Configuration of and results obtained from a hit finding algorithm. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Evaluated ion impact coordinates on the detector. -# Use the depends_on field to specify which reference -# frame the positions are defined. -# -# -# -# -# -# -# -# Defines in which reference frame the positions are defined. -# -# -# -# -# -# CRunHeader.fTotalEventGolden -# -# -# -# -# CRunHeader.fTotalEventIncomplete -# -# -# -# -# CRunHeader.fTotalEventMultiple -# -# -# -# -# CRunHeader.fTotalEventPartials -# -# -# -# -# CRunHeader.fTotalEventRecords -# -# -# -# -# Hit quality is an integer that specifies which category/type a hit was assigned to. -# This field lists the human-readable, possibly though proprietary types distinguished. -# The indices of this array are used in hit_quality to encode hit_quality for each -# pulse in a more efficient way than by repeating the string that is used for each -# type as it is provided in this field. -# -# As an example assume two types golden and partial are distinguished. -# If hit_quality_type stores the array "golden", "partial", the index 0 -# in hit_quality identifies all those pulses of category golden, -# while the index 1 in hit_quality identifies all of category partial. -# -# -# -# -# -# -# -# Hit quality identifier for each pulse. -# Identifier have to be within hit_quality. -# -# -# -# -# -# -# -# This processing yields for each ion with how many others it evaporated -# if these were collected on the same pulse. Extraction of multiple ions -# on one pulse on different or even the same pixel of the detector are possible. -# -# Multiplicity must not be confused with how many atoms of the same element -# a molecular ion contains. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Integer used to name the first pulse to know if there is an -# offset of the evaporation_id to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# evaporation_id_offset and cardinality. For example if identifier run from -# -2 to 3 the value for evaporation_id_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where evaporation_id_offset is 1 and 0 respectively. -# -# -# -# -# (Molecular) ion identifier which resolves the sequence in which -# the ions were evaporated but taking into account that a hit_finding -# and spatial_filtering was applied. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm. -# -# The voltage-and-bowl correction is a data post-processing step to correct ion impact -# positions for flight path differences, detector bias, and nonlinearities. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw time-of-flight data without corrections. -# -# -# -# -# -# -# -# -# The parameter :math:`t_0`, CAnalysis.CCalibMass.fT0Estimate -# -# -# -# -# Calibrated time-of-flight. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses root file which stores -# the settings whereby an RHIT/HITS file can be used to regenerate the -# reconstruction that is here referred to. -# -# The respective RHIT/HITS file should ideally be specified in the serialized -# group of the hit_finding section of this application definition. -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses the resulting typically -# file with the reconstructed positions and (calibrated) mass-to-charge -# state ratio values. -# -# For other data collection/analysis software the data artifact which comes -# closest conceptually to AMETEK/Cameca's typical file formats. -# -# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, -# which should be stored alongside this record in the research data -# management system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The respective ranging definitions file RNG/RRNG/ENV/HDF5. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# (Out-of-sync) background levels in ppm/ns -# reported by e.g. IVAS/APSuite for LEAP systems. -# -# -# -# -# MRP, mass-resolving power, `D. Larson et al. -# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). -# -# -# -# -# MRP, at which mrp_value was specified. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Category for the peak offering a qualitative statement of the location of the peak -# in light of limited mass-resolving power that is relevant for -# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ -# for examples of each category: -# -# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` -# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` -# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states -# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` -# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` -# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml deleted file mode 100644 index 9ff3f1abcd..0000000000 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ /dev/null @@ -1,295 +0,0 @@ -category: base -doc: | - Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. - - Currently ranging definitions in the research field of atom probe face have limitations: - - 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio - values, though, for which not only multiple (molecular) ions are indistinguishable but - also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Indeed, ranging definitions often report only (for each interval) the - mass-to-charge-state-ratio intervals surplus the composition of elements - that build the (molecular) ion. - 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify nuclides from which the (molecular) ion is constructed - and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. - - This base class documents the configuration and results of such an algorithm. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_cand: | - The number of also possible but different (molecular) ions. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - n_variable: | - Number of entries -type: group -NXapm_charge_state_analysis(NXprocess): - - # Details and results of the combinatorial analyses of a ranging definition - # to clarify (if possible) the charge_state of an ion and its (not necessarily) - # unique combination of nuclides contained including their multiplicity. - # input/config - nuclides(NX_UINT): - unit: NX_UNITLESS - doc: | - Input constraint, list of nuclide_hash for typically elements used for the - ranging definition of the ion whose charge state the analyses covered. - The list contains each hash as many times as its multiplicity. - Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. - - As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. - An empty list does not release the constraint. Instead, a list with all elements - in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. - - Keep in mind that with a weakly constrained parameter space the combinatorial - analysis may become very time consuming! - dimensions: - rank: 1 - dim: (n_ivec_max,) - mass_to_charge_range(NX_FLOAT): - unit: NX_ANY - doc: | - Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that an ion qualifies as a candidate. - dimensions: - rank: 2 - dim: (1, 2) - min_half_life(NX_FLOAT): - unit: NX_TIME - doc: | - Input constraint, minimum half life for how long each nuclide of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - min_abundance(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Input constraint, minimum natural abundance of each nuclide of each - (molecular) ion such that the ion qualifies as a candidate. - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - doc: | - If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from - different nuclide instances but the charge_state of all the ions is the same. - - # min_abundance_product(NX_FLOAT): - # doc: | - # For each candidate TO BE DEFINED. - # unit: NX_DIMENSIONLESS - # dim: (n_cand,) - - # output/results - # the n_cand can be 1 in which case all quantities below are scalar - charge_state(NX_INT): - unit: NX_UNITLESS - doc: | - Signed charge, i.e. integer multiple of the elementary - charge of each candidate. - dimensions: - rank: 1 - dim: (n_cand,) - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Table of nuclide instances of which each candidate is composed. - Each row vector is sorted in descending order. Unused values are nullified. - dimensions: - rank: 2 - dim: (n_cand, n_ivec_max) - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Accumulated mass of the nuclides in each candidate. - Not corrected for quantum effects. - dimensions: - rank: 1 - dim: (n_cand,) - natural_abundance_product(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The product of the natural abundances of the nuclides for each candidate. - dimensions: - rank: 1 - dim: (n_cand,) - shortest_half_life(NX_FLOAT): - unit: NX_TIME - doc: | - For each candidate the half life of that nuclide which has the shortest half - life. - dimensions: - rank: 1 - dim: (n_cand,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 269baf13dc37b92fc6b8296cc469bae9de49ac49186adf2fde60b28e9dda1272 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of also possible but different (molecular) ions. -# -# -# -# -# Maximum number of allowed atoms per (molecular) ion (fragment). -# -# -# -# -# Number of entries -# -# -# -# -# Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. -# -# Currently ranging definitions in the research field of atom probe face have limitations: -# -# 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval -# on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio -# values, though, for which not only multiple (molecular) ions are indistinguishable but -# also for which the current practice of documenting classical ranging definitions is incomplete. -# 2. Indeed, ranging definitions often report only (for each interval) the -# mass-to-charge-state-ratio intervals surplus the composition of elements -# that build the (molecular) ion. -# 3. Therefore, classical ranging definitions demand a post-processing with an algorithm -# which can identify nuclides from which the (molecular) ion is constructed -# and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. -# -# This base class documents the configuration and results of such an algorithm. -# -# -# -# -# Input constraint, list of nuclide_hash for typically elements used for the -# ranging definition of the ion whose charge state the analyses covered. -# The list contains each hash as many times as its multiplicity. -# Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. -# -# As an example, a ranging definition H:2 O:1 is configured by setting nuclides to -# a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. -# An empty list does not release the constraint. Instead, a list with all elements -# in the periodic table (encoded as nuclide_hash values) should be used, i.e. -# :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. -# -# Keep in mind that with a weakly constrained parameter space the combinatorial -# analysis may become very time consuming! -# -# -# -# -# -# -# -# Input constraint, interval within which (molecular) ions need to have the -# mass-to-charge-state-ratio such that an ion qualifies as a candidate. -# -# -# -# -# -# -# -# -# Input constraint, minimum half life for how long each nuclide of each -# (molecular) ion needs to be stable such that the ion qualifies as a candidate. -# -# -# -# -# Input constraint, minimum natural abundance of each nuclide of each -# (molecular) ion such that the ion qualifies as a candidate. -# -# -# -# -# If the value is false, it means that non-unique solutions are accepted. -# These are solutions where multiple candidates have been built from -# different nuclide instances but the charge_state of all the ions is the same. -# -# -# -# -# -# -# Signed charge, i.e. integer multiple of the elementary -# charge of each candidate. -# -# -# -# -# -# -# -# Table of nuclide instances of which each candidate is composed. -# Each row vector is sorted in descending order. Unused values are nullified. -# -# -# -# -# -# -# -# -# Accumulated mass of the nuclides in each candidate. -# Not corrected for quantum effects. -# -# -# -# -# -# -# -# The product of the natural abundances of the nuclides for each candidate. -# -# -# -# -# -# -# -# For each candidate the half life of that nuclide which has the shortest half -# life. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_measurement.yaml b/contributed_definitions/nyaml/NXapm_measurement.yaml deleted file mode 100644 index 63d0b18175..0000000000 --- a/contributed_definitions/nyaml/NXapm_measurement.yaml +++ /dev/null @@ -1,40 +0,0 @@ -category: base -doc: | - Base class for documenting a measurement with an atom probe microscope. -type: group -NXapm_measurement(NXobject): - (NXinstrument_apm): - (NXevent_data_apm): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cfbcaef76d663e1534268b0962566339d141ee0823bb436380c4af94b71db259 -# -# -# -# -# -# Base class for documenting a measurement with an atom probe microscope. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_ranging.yaml b/contributed_definitions/nyaml/NXapm_ranging.yaml deleted file mode 100644 index fd3094ece7..0000000000 --- a/contributed_definitions/nyaml/NXapm_ranging.yaml +++ /dev/null @@ -1,188 +0,0 @@ -category: base -doc: | - Base class for the configuration and results of ranging definitions. - - Ranging is a data post-processing step used in the research field of - atom probe during which elemental, isotopic, and/or molecular identities - are assigned to mass-to-charge-state-ratios within a certain interval. - The documentation of these steps is based on ideas that - have been described in the literature: - - * `M. K. Miller `_ - * `D. Haley et al. `_ - * `M. Kühbach et al. `_ -type: group -NXapm_ranging(NXprocess): - (NXprogram): - (NXnote): - mass_to_charge_distribution(NXprocess): - doc: | - Specifies the mass-to-charge-state-ratio histogram. - (NXprogram): - min_incr_max(NX_FLOAT): - unit: NX_ANY - doc: | - Smallest, increment, and largest mass-to-charge-state ratio value. - dimensions: - rank: 1 - dim: (3,) - mass_spectrum(NXdata): - doc: | - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - background_quantification(NXprocess): - doc: | - Details of the background model that was used to - correct the total counts per bin into counts. - (NXprogram): - description(NX_CHAR): - doc: | - To begin with we use a free-text field to learn how - atom probers define a background model. Future versions - of NXapm_ranging can then use this information to parameterize - these models. - - # 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): - doc: | - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - (NXprogram): - (NXpeak): - peak_identification(NXprocess): - doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - (NXprogram): - number_of_ion_types(NX_UINT): - unit: NX_UNITLESS - 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 representing a reserve value. Consequently, - iontypes start counting from 1. - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - unit: NX_UNITLESS - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently, a value of 32 is used (see M. Kühbach et al. `_). - (NXion): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 142cdb67a19fd49f06926b8c3a14834dd93b5dd0fe898929f96c3504e2cccc88 -# -# -# -# -# -# Base class for the configuration and results of ranging definitions. -# -# Ranging is a data post-processing step used in the research field of -# atom probe during which elemental, isotopic, and/or molecular identities -# are assigned to mass-to-charge-state-ratios within a certain interval. -# The documentation of these steps is based on ideas that -# have been 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>`_ -# -# -# -# -# -# Specifies the mass-to-charge-state-ratio histogram. -# -# -# -# -# Smallest, increment, and largest mass-to-charge-state ratio value. -# -# -# -# -# -# -# -# A default histogram aka mass spectrum of -# the mass-to-charge-state ratio values. -# -# -# -# -# -# Details of the background model that was used to -# correct the total counts per bin into counts. -# -# -# -# -# To begin with we use a free-text field to learn how -# atom probers define a background model. Future versions -# of NXapm_ranging can then use this information to parameterize -# these models. -# -# -# -# -# -# -# How where peaks in the background-corrected in the histogram -# of mass-to-charge-state ratio values identified? -# -# -# -# -# -# -# Details about how peaks, with taking into account -# error models, were interpreted as ion types or not. -# -# -# -# -# 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 representing 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 (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml deleted file mode 100644 index 4266e94a05..0000000000 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ /dev/null @@ -1,377 +0,0 @@ -category: base -doc: | - Base class for the configuration and results of a (static) reconstruction algorithm. - - Generating a tomographic reconstruction of the specimen uses selected and - 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. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process - the so-called - evaporation_id, which must not be confused with the pulse_id! -type: group -NXapm_reconstruction(NXprocess): - - # when evolving these ideas further inherit from NXapm_method instead - (NXprogram): - (NXnote): - - # config/input - parameter(NX_CHAR): - 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 this free-text field to guide how to parameterize this better in the - future. For LEAP systems and reconstructions performed with IVAS/APSuite - see `T. Blum et al. `_ (page 371). - primary_element(NX_CHAR): - doc: | - CAnalysis.CSpatial.fPrimaryElement - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - CAnalysis.CSpatial.fEfficiency - flight_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - CAnalysis.CSpatial.fFlightPath - evaporation_field(NX_FLOAT): - unit: NX_ANY - doc: | - CAnalysis.CSpatial.fEvaporationField - image_compression(NX_FLOAT): - unit: NX_UNITLESS - doc: | - CAnalysis.CSpatial.fImageCompression - - Image compression factor (ICF) - kfactor(NX_FLOAT): - unit: NX_UNITLESS - doc: | - CAnalysis.CSpatial.fKfactor - - k factor - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - CAnalysis.CSpatial.fRecoVolume - - Sum of ion volumes - shank_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - CAnalysis.CSpatial.fShankAngle - - Shank angle - tip_radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - CAnalysis.CSpatial.fTipRadius - tip_radius_zero(NX_FLOAT): - unit: NX_LENGTH - doc: | - CAnalysis.CSpatial.fTipRadius0 - voltage_zero(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - CAnalysis.CSpatial.fVoltage0 - protocol_name(NX_CHAR): - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: - open_enum: true - items: [bas, geiser, gault, cameca] - crystallographic_calibration(NX_CHAR): - doc: | - Different strategies for crystallographic calibration of the - reconstruction are possible. Therefore, we collect first such - feedback before parametrizing this further. - - If no crystallographic calibration was performed, the field - should be filled with the n/a, meaning not applied. - obb(NXcollection): - doc: | - Tight, axis-aligned bounding box about the point cloud of the reconstruction. - xmin(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - xmax(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - ymin(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - ymax(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - zmin(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - zmax(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO - - # results - field_of_view(NX_FLOAT): - unit: NX_LENGTH - - # typically in nm reconstruction space not detector coordinates - doc: | - The nominal diameter of the specimen ROI which is measured in the - experiment. The physical specimen cannot be measured completely - because ions may launch but hit in locations other than the detector. - reconstructed_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Three-dimensional reconstructed positions of the ions. - dimensions: - rank: 2 - dim: (n, 3) - \@depends_on(NX_CHAR): - doc: | - The instance of :ref:`NXcoordinate_system` - in which the positions are defined. - naive_discretization(NXprocess): - (NXprogram): - - # config/input - # results - (NXdata): - doc: | - To get a first visual overview of the reconstructed dataset, - here a 3d histogram of the ion is stored. Ion counts are characterized - using one nanometer cubic bins without applying position smoothening - algorithms during the histogram computation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b9d8e611a7239b4bc62f3a49ee204e09c48988bed02f99b8479d34e41f5565fb -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# from which an instance of a reconstructed volume has been generated. -# These ions get new identifier assigned in the process - the so-called -# evaporation_id, which must not be confused with the pulse_id! -# -# -# -# -# Base class for the configuration and results of a (static) reconstruction algorithm. -# -# Generating a tomographic reconstruction of the specimen uses selected and -# 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. -# -# -# -# -# -# -# -# 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 this free-text field to guide how to parameterize this better in the -# future. For LEAP systems and reconstructions performed with IVAS/APSuite -# see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). -# -# -# -# -# CAnalysis.CSpatial.fPrimaryElement -# -# -# -# -# CAnalysis.CSpatial.fEfficiency -# -# -# -# -# CAnalysis.CSpatial.fFlightPath -# -# -# -# -# CAnalysis.CSpatial.fEvaporationField -# -# -# -# -# CAnalysis.CSpatial.fImageCompression -# -# Image compression factor (ICF) -# -# -# -# -# CAnalysis.CSpatial.fKfactor -# -# k factor -# -# -# -# -# CAnalysis.CSpatial.fRecoVolume -# -# Sum of ion volumes -# -# -# -# -# CAnalysis.CSpatial.fShankAngle -# -# Shank angle -# -# -# -# -# CAnalysis.CSpatial.fTipRadius -# -# -# -# -# CAnalysis.CSpatial.fTipRadius0 -# -# -# -# -# CAnalysis.CSpatial.fVoltage0 -# -# -# -# -# Qualitative statement about which reconstruction protocol was used. -# -# -# -# -# -# -# -# -# -# -# Different strategies for crystallographic calibration of the -# reconstruction are possible. Therefore, we collect first such -# feedback before parametrizing this further. -# -# If no crystallographic calibration was performed, the field -# should be filled with the n/a, meaning not applied. -# -# -# -# -# Tight, axis-aligned bounding box about the point cloud of the reconstruction. -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# TODO -# -# -# -# -# -# -# -# The nominal diameter of the specimen ROI which is measured in the -# experiment. The physical specimen cannot be measured completely -# because ions may launch but hit in locations other than the detector. -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# -# -# -# -# -# -# -# The instance of :ref:`NXcoordinate_system` -# in which the positions are defined. -# -# -# -# -# -# -# -# -# To get a first visual overview of the reconstructed dataset, -# here a 3d histogram of the ion is stored. Ion counts are characterized -# using one nanometer cubic bins without applying position smoothening -# algorithms during the histogram computation. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_simulation.yaml b/contributed_definitions/nyaml/NXapm_simulation.yaml deleted file mode 100644 index aed7af33b7..0000000000 --- a/contributed_definitions/nyaml/NXapm_simulation.yaml +++ /dev/null @@ -1,46 +0,0 @@ -category: base -doc: | - Base class for documenting a simulation of removing ions from a specimen and - characterizing them. -type: group -NXapm_simulation(NXobject): - (NXprogram): - (NXparameters): - (NXprocess): - (NXdata): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a8dc849f90829405e50e8fb463dc764e5800f728f35e7bef62a1ac95bbf95499 -# -# -# -# -# -# Base class for documenting a simulation of removing ions from a specimen and -# characterizing them. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXatom.yaml b/contributed_definitions/nyaml/NXatom.yaml deleted file mode 100644 index 4ff8c9f2fc..0000000000 --- a/contributed_definitions/nyaml/NXatom.yaml +++ /dev/null @@ -1,249 +0,0 @@ -category: base -doc: | - Base class for documenting a set of atoms. - - Atoms in the set may be bonded. The set may have - a net charge to represent an ion. - An ion can be a molecular ion. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_pos: | - Number of atom positions. - d: | - Dimensionality -type: group -NXatom(NXobject): - name(NX_CHAR): - doc: | - Given name for the set. - - This field could for example be used in the research field - of atom probe tomography to store a standardized human-readable - name of the element or (molecular) ion like such as Al +++ or 12C +. - identifier_chemical(NX_CHAR): - doc: | - Identifier used to refer to if the set of atoms represents a substance. - enumeration: [inchi] - charge(NX_NUMBER): - unit: NX_CHARGE - doc: | - Signed net (partial) charge of the (molecular) ion. - - Different methods for computing charge are in use. - Care needs to be exercised with respect to the integration. - `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. - charge_state(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Charge reported in multiples of the charge of an electron. - - For research using atom probe tomography the value should be set to - zero if the charge_state is unknown and irrecoverable. This can happen - when classical ranging definition files in formats like RNG, RRNG are used. - These file formats do not document the charge state explicitly but only - the number of atoms of each element per molecular ion surplus the - respective mass-to-charge-state-ratio interval. - - Details on ranging definition files in the literature are `M. K. Miller `_. - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Assumed volume affected by the set of atoms. - - Neither individual atoms nor a set of cluster of these have a volume - that is unique as a some cut-off criterion is required. - indices(NX_CHAR): - doc: | - Index for each atom at locations as detailed by position. - Indices can be used as identifier and thus names for individual atoms. - dimensions: - rank: 1 - dim: (n_pos,) - type(NX_UINT): - unit: NX_UNITLESS - doc: | - Nuclide information for each atom at locations as detailed by position. - - One `approach `_ for storing nuclide information - efficiently is via hashing with the following formula - - :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - - the number of protons and :math:`N` the number of neutrons - of each nuclide given as 8-bit unsigned integer values. - dimensions: - rank: 1 - dim: (n_pos,) - position(NX_NUMBER): - unit: NX_ANY - doc: | - Position of each atom. - dimensions: - rank: 2 - dim: (n_pos, d) - \@reference_frame(NX_CHAR): - doc: | - Path to a reference frame in which positions are defined - to resolve ambiguity when the reference frame is different - to the NeXus default reference frame (McStas). - occupancy(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - - This field is useful for specifying the atomic motif in - instances of :ref:`NXunit_cell`. - dimensions: - rank: 1 - dim: (n_pos,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fc189c70eeb19f2dadb12b90700cfeef10148baf87fd6e71874db0941aeb5aaf -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of atom positions. -# -# -# -# -# Dimensionality -# -# -# -# -# Base class for documenting a set of atoms. -# -# Atoms in the set may be bonded. The set may have -# a net charge to represent an ion. -# An ion can be a molecular ion. -# -# -# -# Given name for the set. -# -# This field could for example be used in the research field -# of atom probe tomography to store a standardized human-readable -# name of the element or (molecular) ion like such as Al +++ or 12C +. -# -# -# -# -# Identifier used to refer to if the set of atoms represents a substance. -# -# -# -# -# -# -# -# Signed net (partial) charge of the (molecular) ion. -# -# Different methods for computing charge are in use. -# Care needs to be exercised with respect to the integration. -# `T. A. Manz <10.1039/c6ra04656h>`_ and `N. G. Limas <10.1039/C6RA05507A>`_ discuss computational details. -# -# -# -# -# Charge reported in multiples of the charge of an electron. -# -# For research using atom probe tomography the value should be set to -# zero if the charge_state is unknown and irrecoverable. This can happen -# when classical ranging definition files in formats like RNG, RRNG are used. -# These file formats do not document the charge state explicitly but only -# the number of atoms of each element per molecular ion surplus the -# respective mass-to-charge-state-ratio interval. -# -# Details on ranging definition files in the literature are `M. K. Miller <https://doi.org/10.1002/sia.1719>`_. -# -# -# -# -# Assumed volume affected by the set of atoms. -# -# Neither individual atoms nor a set of cluster of these have a volume -# that is unique as a some cut-off criterion is required. -# -# -# -# -# Index for each atom at locations as detailed by position. -# Indices can be used as identifier and thus names for individual atoms. -# -# -# -# -# -# -# -# Nuclide information for each atom at locations as detailed by position. -# -# One `approach <https://doi.org/10.1017/S1431927621012241>`_ for storing nuclide information -# efficiently is via hashing with the following formula -# -# :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# -# the number of protons and :math:`N` the number of neutrons -# of each nuclide given as 8-bit unsigned integer values. -# -# -# -# -# -# -# -# Position of each atom. -# -# -# -# -# -# -# -# Path to a reference frame in which positions are defined -# to resolve ambiguity when the reference frame is different -# to the NeXus default reference frame (McStas). -# -# -# -# -# -# Relative occupancy of the atom position. -# -# This field is useful for specifying the atomic motif in -# instances of :ref:`NXunit_cell`. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml deleted file mode 100644 index 0878c0130b..0000000000 --- a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml +++ /dev/null @@ -1,195 +0,0 @@ -category: base -doc: | - Contains data structures of an experimental optical setup (i.e., multiple - transfer matrix tables). These data structures are used to relate physical - properties of two beams (NXbeam) which have one common optical component - (NXcomponent) (one specific transfer matrix). - One of these beams is an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_variables: | - Length of the array associated to the data type. -type: group -NXbeam_transfer_matrix_table(NXobject): - datatype_N: - nameType: partial - doc: | - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - enumeration: [aperture, focal length, orientation, jones matrix] - matrix_elements: - doc: | - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - dimensions: - rank: 1 - dim: (N_variables,) - TRANSFER_MATRIX(NX_NUMBER): - nameType: any - doc: | - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfer matrix relationship between N input beams and M output beams. - It contains a table with the relevant matrices to be used for different - transmitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of a beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfer matrix table has the dimension NxM. - - For each entry, in this transfer matrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfer matrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - dimensions: - rank: 2 - dim: (N_variables, N_variables) - \@input: - doc: | - Specific name of input beam which the transfer matrix table is related to. - \@output: - doc: | - Specific name of output beam which the transfer matrix table is related to. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e900939e0c3c854484795c7abc0217a49b21dc801fe96f5245be2f36633ce3cd -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Length of the array associated to the data type. -# -# -# -# -# Contains data structures of an experimental optical setup (i.e., multiple -# transfer matrix tables). These data structures are used to relate physical -# properties of two beams (NXbeam) which have one common optical component -# (NXcomponent) (one specific transfer matrix). -# One of these beams is an input beam and the other one is an output beam. -# -# The data describes the change of beam properties, e.g. the intensity of a -# beam is reduced because the transmission coefficient of the beam device is -# lower than 1. -# -# -# -# Select which type of data was recorded, for example aperture and -# focal length. -# It is possible to have multiple selections. This selection defines -# how many columns (N_variables) are stored in the data array. -# N in the name, is the index number in which order the given -# property is listed. -# -# -# -# -# -# -# -# -# -# -# Please list in this array the column and row names used in your actual data. -# That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] -# and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix -# ['JM1','JM2'] -# -# -# -# -# -# -# -# Contains the datastructure which relates beam properties of an -# input and output beam as result of the input beam interaction -# with the beam device. -# -# Transfer matrix relationship between N input beams and M output beams. -# It contains a table with the relevant matrices to be used for different -# transmitted properties (such as polarization, intensity, phase). -# -# Data structure for all transfermatrices of a beam device in a setup. -# For each combination of N input and M output beams and for L physical -# concept (i.e. beam intensity), one matrix can be defined. -# -# In this way, the transfer matrix table has the dimension NxM. -# -# For each entry, in this transfer matrix, there are L formalisms. -# Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, -# whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). -# -# A beamsplitter with two input laser beams can have a total of -# four transfermatrices (2 Input x 2 Output). -# -# The dimension of the transfer matrix depends on the parameters. -# Examples are: -# 1x1 for intensity/power -# 2x2 for jones formalism -# 3x3 for direction -# -# -# -# -# -# -# -# Specific name of input beam which the transfer matrix table is related to. -# -# -# -# -# Specific name of output beam which the transfer matrix table is related to. -# -# -# -# \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml deleted file mode 100644 index 80b63a71ee..0000000000 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml +++ /dev/null @@ -1,166 +0,0 @@ -category: base -doc: | - Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about 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 of alpha shapes, and - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings - - in CGAL, the Computational Geometry Algorithms Library respectively. - As a starting point, we follow the conventions of the CGAL library. - - In general, an alpha complex is a not necessarily connected or not necessarily pure complex, - i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific - alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and - regularization can be used to provide details about regularization procedures. - -# The so-called spectrum or sets of (weighted) alpha shapes includes the convex hull of a point set. -type: group -NXcg_alpha_complex(NXcg_primitive): - type: - doc: | - Type of alpha complex following the terminology used by CGAL for now. - - Alpha_shape means meshes created using one of the alpha_shape algorithm. - Alpha_wrapping means meshes created using the alpha_wrapping algorithm. - enumeration: [convex_hull, alpha_shape, alpha_wrapping] - regularization: - doc: | - Human-readable description about regularization procedures. - is_regularized(NX_BOOLEAN): - doc: | - Was the alpha complex regularized, i.e. have singular faces been removed, or not. - alpha(NX_NUMBER): - unit: NX_ANY - doc: | - The alpha parameter, i.e. the squared radius of the alpha-sphere - that is used when computing the alpha complex. - offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - The offset distance parameter used when computing alpha_wrappings. - - # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! - (NXcg_point): - doc: | - Point cloud serving as input for the computation of the alpha complex. - TRIANGLE_SOUP(NXcg_triangle): - nameType: any - doc: | - Triangle soup serving as input for the computation of the alpha complex. - ALPHA_COMPLEX(NXcg_triangle): - nameType: any - doc: | - Triangle mesh representing the output of the computation, i.e. the alpha complex. - TETRAHEDRALIZATION(NXcg_tetrahedron): - nameType: any - doc: | - Tetrahedra representing an interior volume of the alpha complex (if such exists). - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 59c3d4416ee93f243f675a57decff34b5fdef4011a4f03aafc25f7863cf27422 -# -# -# -# -# -# -# Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about 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 of alpha shapes, and -# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings -# -# in CGAL, the Computational Geometry Algorithms Library respectively. -# As a starting point, we follow the conventions of the CGAL library. -# -# In general, an alpha complex is a not necessarily connected or not necessarily pure complex, -# i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific -# alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and -# regularization can be used to provide details about regularization procedures. -# -# -# -# Type of alpha complex following the terminology used by CGAL for now. -# -# Alpha_shape means meshes created using one of the alpha_shape algorithm. -# Alpha_wrapping means meshes created using the alpha_wrapping algorithm. -# -# -# -# -# -# -# -# -# -# Human-readable description about regularization procedures. -# -# -# -# -# Was the alpha complex regularized, i.e. have singular faces been removed, or not. -# -# -# -# -# The alpha parameter, i.e. the squared radius of the alpha-sphere -# that is used when computing the alpha complex. -# -# -# -# -# The offset distance parameter used when computing alpha_wrappings. -# -# -# -# -# -# Point cloud serving as input for the computation of the alpha complex. -# -# -# -# -# Triangle soup serving as input for the computation of the alpha complex. -# -# -# -# -# Triangle mesh representing the output of the computation, i.e. the alpha complex. -# -# -# -# -# Tetrahedra representing an interior volume of the alpha complex (if such exists). -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_cylinder.yaml b/contributed_definitions/nyaml/NXcg_cylinder.yaml deleted file mode 100644 index d4241d7263..0000000000 --- a/contributed_definitions/nyaml/NXcg_cylinder.yaml +++ /dev/null @@ -1,229 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of cylinders or (truncated) cones. - - The radius can either be defined in the radii field or by filling the upper_cap_radii - and lower_cap_radii fields respectively. The latter field case can - thus be used to represent (truncated) cones. - - It is possible to define only one of the cap_radii fields - to represent half-open cylinder. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space in which the members are assumed embedded. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_cylinder(NXcg_primitive): - height(NX_NUMBER): - unit: NX_LENGTH - doc: | - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. - - The upper_cap is assumed to represent the end while the - lower_cap is assumed to represent the start of the - respective cylinder instances when inspecting along the - direction vector. - dimensions: - rank: 2 - dim: (c, d) - radius(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radius of the cylinder if all have the same radius. - radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the cylinder. - dimensions: - rank: 1 - dim: (c,) - upper_cap_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: (c,) - lower_cap_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: (c,) - - # properties of the cylinder - lateral_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Lateral surface area of each cylinder. - dimensions: - rank: 1 - dim: (c,) - upper_cap_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the upper cap of each cylinder. - dimensions: - rank: 1 - dim: (c,) - lower_cap_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the lower cap of each cylinder. - dimensions: - rank: 1 - dim: (c,) - total_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Sum of upper and lower cap area and lateral surface area of each cylinder. - dimensions: - rank: 1 - dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 76c5b4bd257f27b6a670bec467a805643b68451a1ce96c9ecabd18c1499ee413 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the space in which the members are assumed embedded. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of cylinders or (truncated) cones. -# -# The radius can either be defined in the radii field or by filling the upper_cap_radii -# and lower_cap_radii fields respectively. The latter field case can -# thus be used to represent (truncated) cones. -# -# It is possible to define only one of the cap_radii fields -# to represent half-open cylinder. -# -# -# -# A direction vector which is parallel to the cylinder/cone axis -# and whose magnitude is the height of the cylinder/cone. -# -# The upper_cap is assumed to represent the end while the -# lower_cap is assumed to represent the start of the -# respective cylinder instances when inspecting along the -# direction vector. -# -# -# -# -# -# -# -# -# Radius of the cylinder if all have the same radius. -# -# -# -# -# Radii of the cylinder. -# -# -# -# -# -# -# -# Radii of the upper circular cap. -# -# This field, combined with lower_cap_radius can be used to describe -# (eventually truncated) circular cones. -# -# -# -# -# -# -# -# Radii of the upper circular cap. -# -# This field, combined with upper_cap_radius can be used to describe -# (eventually truncated) circular cones. -# -# -# -# -# -# -# -# -# Lateral surface area of each cylinder. -# -# -# -# -# -# -# -# Area of the upper cap of each cylinder. -# -# -# -# -# -# -# -# Area of the lower cap of each cylinder. -# -# -# -# -# -# -# -# Sum of upper and lower cap area and lateral surface area of each cylinder. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid.yaml deleted file mode 100644 index de4540a021..0000000000 --- a/contributed_definitions/nyaml/NXcg_ellipsoid.yaml +++ /dev/null @@ -1,131 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of ellipsoids. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space in which the members are assumed embedded. - c: | - The cardinality of the set, i.e. the number of members. - -# redundant as there is NXcsg, and NXquadric but easier to understand -type: group -NXcg_ellipsoid(NXcg_primitive): - semi_axes_value(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of the semi-axes (e.g. semi-major and semi-minor - respectively for an ellipse). - - Use if all ellipsoids in the set have the same half-axes. - dimensions: - rank: 1 - dim: (d,) - semi_axes_values(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of the semi-axes if ellipsoids have individually different lengths. - dimensions: - rank: 2 - dim: (c, d) - - # convenience dictionary entries when all ellipsoids in the set are spheres. - radius(NX_NUMBER): - unit: NX_LENGTH - doc: | - In the case that all ellipsoids are spheres. - radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - In the case that all ellipsoids are spheres whose radii differ. - For a mixture of spheres use semi_axes_values. - dimensions: - rank: 1 - dim: (c,) - - # properties of ellipsoids - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eff8af12e9566880c60a744fdb0bd00203c6f04da4bdaffedc16def5d6a3bb29 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the space in which the members are assumed embedded. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of ellipsoids. -# -# -# -# Length of the semi-axes (e.g. semi-major and semi-minor -# respectively for an ellipse). -# -# Use if all ellipsoids in the set have the same half-axes. -# -# -# -# -# -# -# -# Length of the semi-axes if ellipsoids have individually different lengths. -# -# -# -# -# -# -# -# -# -# In the case that all ellipsoids are spheres. -# -# -# -# -# In the case that all ellipsoids are spheres whose radii differ. -# For a mixture of spheres use semi_axes_values. -# -# -# -# -# -# -# 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 078efbb0e1..0000000000 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ /dev/null @@ -1,397 +0,0 @@ -category: base -doc: | - Computational geometry of primitives via a face-and-edge-list data structure. - - Primitives must neither be degenerated nor self-intersect but can have different - properties. A face-and-edge-list-based description of primitives is - frequently used for triangles and polyhedra to store them on disk for - visualization purposes (see OFF, PLY, VTK, or STL file formats). - - Although this description is storage efficient, it is not well-suited for - topological analyses. In this case using a half-edge data structure is - an alternative. - - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or detailed specification demands. - - Indices can be used as identifier and thus names for individual instances. -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. - -# duplicate of an NXoff_geometry ? -type: group -NXcg_face_list_data_structure(NXcg_primitive): - - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - dimensions: - rank: 1 - dim: (n_f,) - number_of_edges(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - dimensions: - rank: 1 - dim: (n_e,) - number_of_faces(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of faces of the primitives. - index_offset_vertex(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - index_offset_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - index_offset_face(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive for further details. - indices_vertex(NX_INT): - unit: NX_UNITLESS - doc: | - Integer identifier to distinguish all vertices explicitly. - dimensions: - rank: 1 - dim: (n_v,) - indices_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish all edges explicitly. - dimensions: - rank: 1 - dim: (n_e,) - indices_face(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish all faces explicitly. - dimensions: - rank: 1 - dim: (n_f,) - vertices(NX_NUMBER): - unit: NX_ANY - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in more efficient storage. Alternatively, storing vertex positions naively - should be indicated with setting vertices_are_unique to False. - Naively means that each vertex is stored even though many vertices may - share the same positions. - dimensions: - rank: 2 - dim: (n_v, d) - edges(NX_INT): - unit: NX_UNITLESS - doc: | - The edges are stored as pairs of vertex identifier. - dimensions: - rank: 2 - dim: (n_e, 2) - faces(NX_INT): - unit: NX_UNITLESS - doc: | - The faces are stored as a concatenated array of vertex identifier tuples. - - 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: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 1 - dim: (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 more - than once. - edges_are_unique(NX_BOOLEAN): - doc: | - If true, indicates that no edge is stored more than once. - - Users are encouraged to consider using a half_edge_data_structure instead. - faces_are_unique(NX_BOOLEAN): - doc: | - If true, indicates that no face is stored more than once. - winding_order(NX_INT): - unit: NX_UNITLESS - doc: | - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - dimensions: - rank: 1 - dim: (n_f,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0c3df1a1a9726e2c06714aa526c35a2f5ac3da333275277f7ab65f85e663b105 -# -# -# -# -# -# -# -# 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. -# -# -# -# -# Computational geometry of primitives via a face-and-edge-list data structure. -# -# Primitives must neither be degenerated nor self-intersect but can have different -# properties. A face-and-edge-list-based description of primitives is -# frequently used for triangles and polyhedra to store them on disk for -# visualization purposes (see OFF, PLY, VTK, or STL file formats). -# -# Although this description is storage efficient, it is not well-suited for -# topological analyses. In this case using a half-edge data structure is -# an alternative. -# -# Having an own base class for the data structure how primitives are stored is -# useful to embrace both users with small or detailed specification demands. -# -# Indices can be used as identifier and thus names for individual instances. -# -# -# -# -# Number of vertices for each face. -# -# Each entry represents the total number of vertices for that face, -# irrespectively whether vertices are shared among faces or not. -# -# -# -# -# -# -# -# Number of edges for each face. -# -# Each entry represents the total number of edges for that face, -# irrespectively whether edges are shared across faces or not. -# -# -# -# -# -# -# -# Number of faces of the primitives. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the vertices differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the edges differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the faces differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive for further details. -# -# -# -# -# Integer identifier to distinguish all vertices explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish all edges explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish all faces explicitly. -# -# -# -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to a unique set as this may -# result in more efficient storage. Alternatively, storing vertex positions naively -# should be indicated with setting vertices_are_unique to False. -# Naively means that each vertex is stored even though many vertices may -# share the same positions. -# -# -# -# -# -# -# -# -# The edges are stored as pairs of vertex identifier. -# -# -# -# -# -# -# -# -# The faces are stored as a concatenated array of vertex identifier tuples. -# -# 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: :math:`[\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 more -# than once. -# -# -# -# -# If true, indicates that no edge is stored more than once. -# -# Users are encouraged to consider using a half_edge_data_structure instead. -# -# -# -# -# If true, indicates that no face is stored more than once. -# -# -# -# -# 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_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml deleted file mode 100644 index 890b507d60..0000000000 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ /dev/null @@ -1,308 +0,0 @@ -category: base -doc: | - Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - - Three-dimensional grids with cubic cells are if not the most frequently used - example of such grids. Numerical methods and models that use grids are used - in many cases in the natural sciences and engineering disciplines. Examples are - discretizations in space and time used for phase-field, cellular automata, or Monte Carlo - modeling. -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 aka grid points. - n_b: | - Number of boundaries of the bounding box or primitive housing the grid. -type: group -NXcg_grid(NXcg_primitive): - origin(NX_NUMBER): - unit: NX_ANY - doc: | - Location of the origin of the grid. - - Use the depends_on field that is inherited from the :ref:`NXcg_primitive` - class to specify the coordinate system in which the origin location is defined. - dimensions: - rank: 1 - dim: (d,) - symmetry(NX_CHAR): - doc: | - The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - doc: | - The unit cell dimensions using crystallographic notation. - dimensions: - rank: 1 - dim: (d,) - extent(NX_INT): - unit: NX_UNITLESS - 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. - dimensions: - rank: 1 - dim: (d,) - - # number_of_cells(NX_UINT): maybe already too trivial quantities - # should constraints on the grid be place here or not - position(NX_NUMBER): - unit: NX_ANY - doc: | - Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: (c, d) - coordinate(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - Coordinate of each cell with respect to the discrete grid. - dimensions: - rank: 2 - dim: (c, d) - - # this should be a ROI - bounding_box(NXcg_polyhedron): - doc: | - A tight bounding box about the grid. - - # does it have to be a tight bounding box? - # 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_UINT): - unit: NX_UNITLESS - doc: | - Number of boundaries distinguished - - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - boundaries(NX_CHAR): - doc: | - Name of domain boundaries of the simulation box/ROI - e.g. left, right, front, back, bottom, top. - dimensions: - rank: 1 - dim: (n_b,) - boundary_conditions(NX_INT): - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: (n_b,) - surface_reconstruction(NX_CHAR): - doc: | - Details about the computational geometry method and implementation - used for discretizing internal surfaces as e.g. obtained with marching methods, - like marching squares or marching cubes. - - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. - 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 ideally be an identifier of a program. - If not possible, an identifier for a paper, technical report, or free-text - description can be used instead. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c5bee596e67c2209b40728d8aef705108736ff7e8edce3781bd661d458bfbe13 -# -# -# -# -# -# -# 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 aka grid points. -# -# -# -# -# Number of boundaries of the bounding box or primitive housing the grid. -# -# -# -# -# Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. -# -# Three-dimensional grids with cubic cells are if not the most frequently used -# example of such grids. Numerical methods and models that use grids are used -# in many cases in the natural sciences and engineering disciplines. Examples are -# discretizations in space and time used for phase-field, cellular automata, or Monte Carlo -# modeling. -# -# -# -# Location of the origin of the grid. -# -# Use the depends_on field that is inherited from the :ref:`NXcg_primitive` -# class to specify the coordinate system in which the origin location is defined. -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# Coordinate of each cell with respect to the discrete grid. -# -# -# -# -# -# -# -# -# -# A tight bounding box about the grid. -# -# -# -# -# -# Number of boundaries distinguished -# -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# Name of domain boundaries of the simulation box/ROI -# 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 -# -# -# -# -# -# -# -# -# Details about the computational geometry method and implementation -# used for discretizing internal surfaces as e.g. obtained with marching methods, -# like marching squares or marching cubes. -# -# Documenting which specific version was used helps with understanding how -# robust the results are with respect to the topology of the triangulation. -# 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 ideally be an identifier of a program. -# If not possible, an identifier for a paper, technical report, or free-text -# description can be used instead. -# -# -# 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 db5d3a300f..0000000000 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ /dev/null @@ -1,341 +0,0 @@ -category: base -doc: | - Computational geometry 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. The data structure is also - known as a doubly connected edge list. - - Indices can be used as identifier and thus names for individual instances. - -# 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. -type: group -NXcg_half_edge_data_structure(NXcg_primitive): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - doc: | - Dimensionality of the primitives described. - - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - dimensions: - rank: 1 - dim: (n_f,) - number_of_edges(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - dimensions: - rank: 1 - dim: (n_he,) - index_offset_vertex(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - index_offset_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - index_offset_face(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive` for further details. - - # therefore, indices_ -vertex, -face, -half_edge are implicit - position(NX_NUMBER): - unit: NX_ANY - doc: | - The position of the vertices. - dimensions: - rank: 2 - dim: (n_v, d) - vertex_incident_half_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the incident half-edge. - dimensions: - rank: 1 - dim: (n_v,) - face_half_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the (starting)/associated half-edge of the face. - dimensions: - rank: 1 - dim: (n_f,) - half_edge_vertex_origin(NX_INT): - unit: NX_UNITLESS - doc: | - The identifier of the vertex from which this half-edge is outwards pointing. - dimensions: - rank: 1 - dim: (n_he,) - half_edge_twin(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the associated oppositely pointing half-edge. - dimensions: - rank: 1 - dim: (n_he,) - half_edge_incident_face(NX_INT): - unit: NX_UNITLESS - doc: | - If the half-edge is a boundary half-edge the - incident face identifier is NULL, i.e. 0. - dimensions: - rank: 1 - dim: (n_he,) - half_edge_next(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the next half-edge. - dimensions: - rank: 1 - dim: (n_he,) - half_edge_prev(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the previous half-edge. - dimensions: - rank: 1 - dim: (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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b10ac48eea45ef41a87c498cb5948f0214ae0b644dac489dba9373b8f3afcff6 -# -# -# -# -# -# -# -# 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 geometry 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. The data structure is also -# known as a doubly connected edge list. -# -# Indices can be used as identifier and thus names for individual instances. -# -# -# -# Dimensionality of the primitives described. -# -# -# -# -# -# Number of vertices for each face. -# -# Each entry represents the total number of vertices for that face, -# irrespectively whether vertices are shared among faces or not. -# -# -# -# -# -# -# -# Number of edges for each face. -# -# Each entry represents the total number of edges for that face, -# irrespectively whether edges are shared across faces or not. -# -# -# -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the vertices differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive` for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the edges differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive` for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the faces differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive` for further details. -# -# -# -# -# -# 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.yaml b/contributed_definitions/nyaml/NXcg_hexahedron.yaml deleted file mode 100644 index f2af5f16d8..0000000000 --- a/contributed_definitions/nyaml/NXcg_hexahedron.yaml +++ /dev/null @@ -1,342 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of hexahedra in Euclidean space. - - 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 an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional 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. - - As a specialization of the :ref:`NXcg_primitive` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making 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 - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. -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. - -# 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 simplices 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 -type: group -NXcg_hexahedron(NXcg_primitive): - - # qualifiers and properties of hexahedra - shape(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier for the shape of each hexahedron. - dimensions: - rank: 2 - dim: (c, 3) - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: (c,) - width(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. - dimensions: - rank: 1 - dim: (c,) - height(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. - dimensions: - rank: 1 - dim: (c,) - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of each hexahedron. - dimensions: - rank: 1 - dim: (c,) - area(NX_NUMBER): - unit: NX_AREA - doc: | - Total (surface) area (of all six faces) of each hexahedron. - dimensions: - rank: 1 - dim: (c,) - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of the six faces of each hexahedron. - dimensions: - rank: 2 - dim: (c, 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: (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 coordinate system. - dimensions: - rank: 1 - dim: (c,) - vertex_normal(NXcg_unit_normal): - edge_normal(NXcg_unit_normal): - face_normal(NXcg_unit_normal): - - # detailed mesh-based representation - hexahedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all hexahedra. - hexahedronID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of each hexahedron. - hexahedron_half_edgeID(NXcg_half_edge_data_structure): - nameType: partial - doc: | - Individual storage of each hexahedron as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9a91e731a011f357acdd1310cdece4aa43a4ec09ec35774d98505a570d5e986d -# -# -# -# -# -# -# -# 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. -# -# 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 an approach whereby -# different specific views can be implemented using the same base class: -# -# * In the simplest case experimentalists may use this base class to describe -# the dimensions or size of a specimen. In this case the alignment with axes -# is not relevant as eventually only the volume of the specimen is of interest. -# * In many cases, take for example an experiment where a specimen was cut out -# from a specifically deformed piece of material, the orientation of the -# specimen's edges with the experiment coordinate system is of high relevance. -# Examples include knowledge about the specimen edge, whether it is -# parallel to the rolling, the transverse, or the normal direction. -# * While the above-mentioned use cases are sufficient to pinpoint the sample -# within a known laboratory/experiment coordinate system, these descriptions -# are not detailed enough to specify e.g. a CAD model of the specimen. -# * Therefore, groups and fields for an additional, computational-geometry- -# based view of hexahedra is offered to serve additional 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. -# -# As a specialization of the :ref:`NXcg_primitive` base class hexahedra -# are assumed non-degenerated, closed, and built of polygons that are -# not self-intersecting. -# -# The term hexahedra will be used throughout this base class but includes -# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), -# and optimal bounding box (OBB). -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a cuboid whose edges are aligned with the -# base vectors of a coordinate system. As a part of binary trees, these data -# objects are important for making 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 -# tightly fitting box about an arbitrary object. In general, such boxes are -# rotated. Exact and substantially faster in practice approximate algorithms -# exist to compute optimal or near optimal bounding boxes for sets of points. -# -# -# -# -# Qualifier for the shape of each hexahedron. -# -# -# -# -# -# -# -# -# Qualifier that is useful in cases when one edge is longer than all other -# edges of the hexahedra. Often the term length is associated with the -# assumption that one edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the horizontal -# direction assuming a specific coordinate system. -# -# For the sake of explicitness quantities like length, width, and height -# should not be reported without specifying also the assumed reference frame. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the vertical -# direction assuming a specific coordinate system. -# -# -# -# -# -# -# -# Volume of each hexahedron. -# -# -# -# -# -# -# -# Total (surface) 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 coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all hexahedra. -# -# -# -# -# Individual storage of each hexahedron. -# -# -# -# -# Individual storage of each hexahedron as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram.yaml b/contributed_definitions/nyaml/NXcg_parallelogram.yaml deleted file mode 100644 index ab6ec8ab40..0000000000 --- a/contributed_definitions/nyaml/NXcg_parallelogram.yaml +++ /dev/null @@ -1,172 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of parallelograms. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing 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, i.e. - most tightly 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 an optimal bounding box to a point set 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. -type: group -NXcg_parallelogram(NXcg_primitive): - - # qualifiers and properties of parallelograms - is_rectangle(NX_BOOLEAN): - doc: | - To specify which parallelogram is a rectangle. - dimensions: - rank: 1 - dim: (c,) - is_axis_aligned(NX_BOOLEAN): - doc: | - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. - dimensions: - rank: 1 - dim: (c,) - - # detailed mesh-based representation - parallelograms(NXcg_face_list_data_structure): - doc: | - Combined storage of all parallelograms. - parallelogramID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of each parallelogram. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 925993111384a8a2e209475675f51f560114d21c32b9ed50c5f4f8db413a87af -# -# -# -# -# -# -# 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. -# -# This class can also be used to describe rectangles or squares, irrespective -# whether these are axis-aligned or not. The class represents different -# access and description levels to embrace applied scientists and computational -# geometry experts with their different views: -# -# * The simplest case is the communication of dimensions aka the size of a -# region of interest in the 2D plane. In this case, communicating the -# alignment with axes is maybe not as relevant as it is to report the area -# of the ROI. -# * In other cases the extent of the parallelogram is relevant though. -# * Finally, in CAD models it should be possible to specify the polygons -# which the parallelograms represent with exact numerical details. -# -# Parallelograms are important geometrical primitives as their usage for -# describing many scanning experiments shows where typically parallelogram-shaped -# ROIs are scanned across the surface of a sample. -# -# The term parallelogram will be used throughout this base class thus including -# the important special cases rectangle, square, 2D box, axis-aligned bounding box -# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D -# counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a rectangle whose edges are aligned with the -# axes of a coordinate system. As a part of binary trees AABBs are important data -# objects for executing 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, i.e. -# most tightly 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 an optimal bounding box to a point set in 2D. -# -# -# -# -# To specify which parallelogram is a rectangle. -# -# -# -# -# -# -# -# Only to be used if is_rectangle is present. In this case, this field -# describes whether parallelograms are rectangles whose primary edges -# are parallel to the axes of the coordinate system. -# -# -# -# -# -# -# -# -# Combined storage of all parallelograms. -# -# -# -# -# Individual storage of each parallelogram. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_point.yaml b/contributed_definitions/nyaml/NXcg_point.yaml deleted file mode 100644 index 33db7ec47b..0000000000 --- a/contributed_definitions/nyaml/NXcg_point.yaml +++ /dev/null @@ -1,139 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of points. - - Points may have an associated time value. Users are advised though to store - time data of point sets rather as instances of time events, where for each - point in time there is an :ref:`NXcg_point` 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 (real time or - simulated physical time). Thereby, the storage of redundant timestamp - information per point is considered as obsolete. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality. - c: | - The cardinality of the set, i.e. the number of points. -type: group -NXcg_point(NXcg_primitive): - position(NX_NUMBER): - unit: NX_ANY - doc: | - Coordinates of the points. - dimensions: - rank: 2 - dim: (c, d) - time(NX_NUMBER): - unit: NX_TIME - doc: | - (Elapsed) time for each point. - - If the field time is needed contextualize the time_offset relative to which - time values are defined. Alternative store timestamp. - dimensions: - rank: 1 - dim: (c,) - timestamp(NX_DATE_TIME): - doc: | - ISO8601 with local time zone offset for each point. - dimensions: - rank: 1 - dim: (c,) - time_offset(NX_DATE_TIME): - doc: | - ISO8601 with local time zone offset that serves as the reference - for values in the field time. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 14c313890564590cf516821eca33c4e26bed72d15a8078e0dc52a5bff904ad30 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality. -# -# -# -# -# The cardinality of the set, i.e. the number of points. -# -# -# -# -# Computational geometry description of a set of points. -# -# Points may have an associated time value. Users are advised though to store -# time data of point sets rather as instances of time events, where for each -# point in time there is an :ref:`NXcg_point` 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 (real time or -# simulated physical time). Thereby, the storage of redundant timestamp -# information per point is considered as obsolete. -# -# -# -# Coordinates of the points. -# -# -# -# -# -# -# -# -# (Elapsed) time for each point. -# -# If the field time is needed contextualize the time_offset relative to which -# time values are defined. Alternative store timestamp. -# -# -# -# -# -# -# -# ISO8601 with local time zone offset for each point. -# -# -# -# -# -# -# -# ISO8601 with local time zone offset that serves as the reference -# for values in the field time. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polygon.yaml b/contributed_definitions/nyaml/NXcg_polygon.yaml deleted file mode 100644 index dffc47c0c5..0000000000 --- a/contributed_definitions/nyaml/NXcg_polygon.yaml +++ /dev/null @@ -1,217 +0,0 @@ -category: base - -# similar design like NXoff_geometry but easier to understand -doc: | - Computational geometry description of a set of polygons in Euclidean space. - - Polygons 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes 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 to describe such even more complex primitives instead - of abusing this base class for such purposes. -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. -type: group -NXcg_polygon(NXcg_primitive): - number_of_total_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of vertices in the set. - - # detailed mesh-based representation - polygons(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all polygons. - polygonID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of the mesh of each polygon. - polygon_half_edgeID(NXcg_half_edge_data_structure): - nameType: partial - doc: | - Individual storage of each polygon as a graph. - - # properties of the polygon primitives - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - For each polygon its accumulated length along its edges. - dimensions: - rank: 1 - dim: (c,) - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Interior angles for each polygon. There are as many values per polygon - as the are 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. - dimensions: - rank: 1 - dim: (n_total,) - shape(NX_INT): - unit: NX_UNITLESS - doc: | - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - dimensions: - rank: 1 - dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ded952e63a14b6ad0b6ffba82f480094a26d6772489df7a6e7c13df277077d41 -# -# -# -# -# -# -# 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed -# polyhedra. Even more general complexes can be thought of. An example are the -# so-called piecewise-linear complexes used in the TetGen library. -# -# As these complexes 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 to describe such even more complex primitives instead -# of abusing this base class for such purposes. -# -# -# -# The total number of vertices in the set. -# -# -# -# -# -# Combined storage of all primitives of all polygons. -# -# -# -# -# Individual storage of the mesh of each polygon. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# -# -# -# -# For each polygon its accumulated length along its edges. -# -# -# -# -# -# -# -# Interior angles for each polygon. There are as many values per polygon -# as the are 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 -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron.yaml b/contributed_definitions/nyaml/NXcg_polyhedron.yaml deleted file mode 100644 index 2fce55510d..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyhedron.yaml +++ /dev/null @@ -1,190 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon`. -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. - -# 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 simplices 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. -type: group -NXcg_polyhedron(NXcg_primitive): - - # qualifiers and properties of polyhedra - number_of_faces(NX_UINT): - unit: NX_UNITLESS - doc: | - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. - dimensions: - rank: 1 - dim: (c,) - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of faces. - dimensions: - rank: 1 - dim: (n_f_total,) - number_of_edges(NX_UINT): - doc: | - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counted for each polyhedron. - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each edge. - dimensions: - rank: 1 - dim: (n_e_total,) - - # detailed mesh-based representation - polyhedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all polyhedra. - polyhedronID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of each polyhedron. - polyhedron_half_edgeID(NXcg_half_edge_data_structure): - nameType: partial - doc: | - Individual storage of each polygon as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2268cd65f210df7756fba0491d0e970f7155b246640a0695d05778ef3de5ee93 -# -# -# -# -# -# -# -# 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 set of polyhedra in Euclidean space. -# -# Polyhedra or so-called cells (especially in the convex of tessellations) are -# constructed from polygon meshes. Polyhedra may make contact to allow a usage -# of this base class for a description of tessellations. -# -# For the description of more complicated manifolds and especially for polyhedra -# with holes, users are advised to check if their particular needs are described -# by creating customized instances of an :ref:`NXcg_polygon`. -# -# -# -# -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. -# -# -# -# -# -# -# -# Area of each of faces. -# -# -# -# -# -# -# -# The number of edges for each polyhedron. Edges of adjoining polyhedra -# are counted for each polyhedron. -# -# -# -# -# Length of each edge. -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all polyhedra. -# -# -# -# -# Individual storage of each polyhedron. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polyline.yaml b/contributed_definitions/nyaml/NXcg_polyline.yaml deleted file mode 100644 index 26e3a753e1..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyline.yaml +++ /dev/null @@ -1,238 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of polylines. - - 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 traversal along the polyline when - walking from the first to the 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. -type: group -NXcg_polyline(NXcg_primitive): - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcg_point` which defines the - location of the vertices that are referred to in this - NXcg_polyline instance. - number_of_unique_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of vertices that have different positions. - number_of_total_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of vertices, irrespective of their eventual uniqueness. - number_of_vertices(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of vertices of each polyline, irrespectively - whether vertices are shared by vertices or not. - dimensions: - rank: 1 - dim: (c,) - - # 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. - vertices(NX_NUMBER): - unit: NX_ANY - doc: | - Positions of the vertices which support the members of the polyline set. - - Users are encouraged to reduce the vertices to unique positions and vertices - as this often supports with storing geometry data more efficiently. - 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 stores each vertex of a triangle mesh - even though many vertices are shared between triangles and thus - storing multiple copies of their positions is redundant. - dimensions: - rank: 2 - dim: (n_v, 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 several times. - polylines(NX_INT): - unit: NX_UNITLESS - doc: | - Sequence of identifier for vertices how they build each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet at a vertex (assume for example that the second vertex - is shared and marking the junction between the two polylines), it is possible - that there are only five unique positions. This suggests to store five - unique vertices. - - A non-trivial example is a set with several polylines. Assume that each - has a different number of vertices. The array stores the identifier of - the vertices in the sequence how the polylines are visited: - - The first entry is the identifier of the first vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the first polyline. - Thereafter, the first vertex of the second polyline, and so on and so forth. - Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), - the vertices of the N-th polyline can be accessed on the array - index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. - dimensions: - rank: 1 - dim: (n_total,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b14cc08d68ff1d70e5adca4bb17904235e53d9c9d2fd6c3aa5438efa188a2fed -# -# -# -# -# -# -# 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. -# -# 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 traversal along the polyline when -# walking from the first to the last vertex. -# -# -# -# Reference to an instance of :ref:`NXcg_point` which defines the -# location of the vertices that are referred to in this -# NXcg_polyline instance. -# -# -# -# -# The total number of vertices that have different positions. -# -# -# -# -# The total number of vertices, irrespective of their eventual uniqueness. -# -# -# -# -# The total number of vertices of each polyline, irrespectively -# whether vertices are shared by vertices or not. -# -# -# -# -# -# -# -# -# Positions of the vertices which support the members of the polyline set. -# -# Users are encouraged to reduce the vertices to unique positions and vertices -# as this often supports with storing geometry data more efficiently. -# 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 stores each vertex of a triangle mesh -# even though many vertices are shared between triangles and thus -# storing multiple copies of their positions is redundant. -# -# -# -# -# -# -# -# -# If true indicates that the vertices are all placed at different -# positions and have different identifiers, i.e. no points overlap -# or are counted several times. -# -# -# -# -# Sequence of identifier for vertices how they build each polyline. -# -# A trivial example is a set with two polylines with three vertices each. -# If the polylines meet at a vertex (assume for example that the second vertex -# is shared and marking the junction between the two polylines), it is possible -# that there are only five unique positions. This suggests to store five -# unique vertices. -# -# A non-trivial example is a set with several polylines. Assume that each -# has a different number of vertices. The array stores the identifier of -# the vertices in the sequence how the polylines are visited: -# -# The first entry is the identifier of the first vertex of the first polyline, -# followed by the second vertex of the first polyline, until the last vertex -# of the first polyline. -# Thereafter, the first vertex of the second polyline, and so on and so forth. -# Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), -# the vertices of the N-th polyline can be accessed on the array -# index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_primitive.yaml b/contributed_definitions/nyaml/NXcg_primitive.yaml deleted file mode 100644 index bb8b776909..0000000000 --- a/contributed_definitions/nyaml/NXcg_primitive.yaml +++ /dev/null @@ -1,432 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the embedding space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive(NXobject): - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives - are defined. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The dimensionality of the primitive set with value up to d. - enumeration: - - # add when 1521 has been merged open="true" - items: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The cardinality of the primitive set. Value should be equal to c. - index_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Indices can be used as identifiers and thus names of instances. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - index_offset and cardinality. For example if identifier run from - -2 to 3 the value for index_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where index_offset is 1 and 0 respectively. - indices(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dimensions: - rank: 1 - dim: (c,) - center(NX_NUMBER): - unit: NX_ANY - doc: | - The center of each primitive - dimensions: - rank: 2 - dim: (c, d) - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dimensions: - rank: 1 - dim: (c,) - shape(NX_NUMBER): - unit: NX_LENGTH - doc: | - Shape of each primitive - dimensions: - rank: 2 - dim: (c, d) - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: (c,) - width(NX_NUMBER): - unit: NX_LENGTH - doc: | - Width of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: (c,) - height(NX_NUMBER): - unit: NX_LENGTH - doc: | - Height of each primitive - - Often the term is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dimensions: - rank: 1 - dim: (c,) - volume(NX_NUMBER): - unit: NX_ANY - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - Volume is an N-D concept for values of dimensionality larger than 1, - Area is an alias for the two-dimensional case. - dimensions: - rank: 1 - dim: (c,) - area(NX_NUMBER): - unit: NX_AREA - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - dimensions: - rank: 1 - dim: (c,) - orientation(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - dimensions: - rank: 2 - dim: (c, d) - is_mesh(NX_BOOLEAN): - doc: | - Do the primitives define a mesh. - is_triangle_mesh(NX_BOOLEAN): - doc: | - Do the primitives define a triangle mesh or not. - is_surface_mesh(NX_BOOLEAN): - doc: | - Do the primitives discretize the surface of an object or not. - is_geodesic_mesh(NX_BOOLEAN): - doc: | - Do the primitives define a geodesic mesh or not. - - A geodesic surface mesh is a triangulated surface mesh with metadata which - can be used as an approximation to describe the surface of a sphere. - Triangulation of spheres are commonly used in Materials Science - for quantifying texture of materials, i.e. the relative rotation of - crystals to sample directions. - - For additional details or an introduction into the topic of geodesic meshes - see (from which specifically the section on subdivision schemes is relevant). - - * `E. S. Popko and C. J. Kitrick `_ - - Earth scientists 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 software. For now we propose to use this - base class as a container for organizing data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - e.g. a geodesic (surface) mesh was instantiated as there are many - possibilities to do so. - description: - doc: | - Possibility to store details such as when primitives form a (specific) type - of mesh such as geodesic meshes. - vertex_normal(NXcg_unit_normal): - edge_normal(NXcg_unit_normal): - face_normal(NXcg_unit_normal): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 65f66dd89993d2350d6905134228c02bcc0bb2608e12fadfd29b8e2730de164a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the embedding space. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of primitives in Euclidean space. -# -# Primitives must neither be degenerated nor self-intersect. -# Individual primitives can differ in their properties (e.g. size, shape, rotation). -# -# -# -# Reference to an instance of :ref:`NXcoordinate_system` in which these primitives -# are defined. -# -# -# -# -# The dimensionality of the primitive set with value up to d. -# -# -# -# -# -# -# -# -# -# -# The cardinality of the primitive set. Value should be equal to c. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the set differs from zero. -# -# Indices can be used as identifiers and thus names of instances. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# index_offset and cardinality. For example if identifier run from -# -2 to 3 the value for index_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where index_offset is 1 and 0 respectively. -# -# -# -# -# Identifier of each member for explicit indexing. -# -# -# -# -# -# -# -# The center of each primitive -# -# -# -# -# -# -# -# -# True if the center is a center of mass. -# -# -# -# -# -# -# -# Shape of each primitive -# -# -# -# -# -# -# -# -# Length of each primitive -# -# Often the term is associated with the assumption that one -# edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Width of each primitive -# -# Often the term is associated with the assumption that one -# edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Height of each primitive -# -# Often the term is associated with the assumption that one -# edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# True if primitive is closed such that it has properties like area or volume. -# -# -# -# -# -# -# -# Volume of each primitive. -# -# Set to NaN if does not apply for primitives for which is_closed is False. -# Volume is an N-D concept for values of dimensionality larger than 1, -# Area is an alias for the two-dimensional case. -# -# -# -# -# -# -# -# Alias for surface_area of each primitive. -# -# Set to NaN if does not apply for primitives for which is_closed is False. -# -# -# -# -# -# -# -# Direction unit vector which points along the -# longest principal axis of each primitive. -# -# Use the depends_on attribute to specify in which coordinate system -# these direction unit vectors are defined. -# -# -# -# -# -# -# -# -# Do the primitives define a mesh. -# -# -# -# -# Do the primitives define a triangle mesh or not. -# -# -# -# -# Do the primitives discretize the surface of an object or not. -# -# -# -# -# Do the primitives define a geodesic mesh or not. -# -# A geodesic surface mesh is a triangulated surface mesh with metadata which -# can be used as an approximation to describe the surface of a sphere. -# Triangulation of spheres are commonly used in Materials Science -# for quantifying texture of materials, i.e. the relative rotation of -# crystals to sample directions. -# -# For additional details or an introduction into the topic of geodesic meshes -# see (from which specifically the section on subdivision schemes is relevant). -# -# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ -# -# Earth scientists 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 software. For now we propose to use this -# base class as a container for organizing data related to geodesic meshes. -# -# Specifically an instance of this base class should detail the rule set how -# e.g. a geodesic (surface) mesh was instantiated as there are many -# possibilities to do so. -# -# -# -# -# Possibility to store details such as when primitives form a (specific) type -# of mesh such as geodesic meshes. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_roi.yaml b/contributed_definitions/nyaml/NXcg_roi.yaml deleted file mode 100644 index 21180b2c9c..0000000000 --- a/contributed_definitions/nyaml/NXcg_roi.yaml +++ /dev/null @@ -1,77 +0,0 @@ -category: base -doc: | - Base class for a region-of-interest (ROI) bound by geometric primitives. - - So-called region-of-interest(s) (ROIs) are typically used to describe a - region in space (and time) where an observation is made or for which - a computer simulation is performed with given boundary conditions. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to - define explicitly the reference frame in which the primitives are - defined. - -# eventually redundant NXsolid_geometry? -type: group -NXcg_roi(NXobject): - (NXcg_ellipsoid): - (NXcg_cylinder): - (NXcg_parallelogram): - (NXcg_hexahedron): - (NXcg_polyhedron): - - # how to handle cases where multiple primitives should be included? - # see comment to NXcg_triangle roi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3227a9f16fd3ed1e325ec7ccb157fea7397a3855d2664809641eff45bd83caad -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to -# define explicitly the reference frame in which the primitives are -# defined. -# -# -# -# Base class for a region-of-interest (ROI) bound by geometric primitives. -# -# So-called region-of-interest(s) (ROIs) are typically used to describe a -# region in space (and time) where an observation is made or for which -# a computer simulation is performed with given boundary conditions. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron.yaml deleted file mode 100644 index 270684044b..0000000000 --- a/contributed_definitions/nyaml/NXcg_tetrahedron.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of tetrahedra. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. -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. -type: group -NXcg_tetrahedron(NXcg_primitive): - - # qualifiers and properties of tetrahedra - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of the four triangular faces of each tetrahedron. - dimensions: - rank: 2 - dim: (c, 4) - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each edge of each tetrahedron. - dimensions: - rank: 2 - dim: (c, 6) - tetrahedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all tetrahedra. - tetrahedronID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of each tetrahedron. - tetrahedron_half_edgeID(NXcg_half_edge_data_structure): - nameType: partial - doc: | - Individual storage of each tetrahedron as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f772d6a0bf5b431dc18eb9da83598d71137a3c858351d4290df0a101c89759e5 -# -# -# -# -# -# -# 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. -# -# Among hexahedral elements, tetrahedral elements are one of the most -# frequently used geometric primitive for meshing and describing volumetric -# objects in continuum-field simulations. -# -# -# -# -# Area of each of the four triangular faces of each tetrahedron. -# -# -# -# -# -# -# -# -# Length of each edge of each tetrahedron. -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all tetrahedra. -# -# -# -# -# Individual storage of each tetrahedron. -# -# -# -# -# Individual storage of each tetrahedron as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_triangle.yaml b/contributed_definitions/nyaml/NXcg_triangle.yaml deleted file mode 100644 index 0654914fac..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangle.yaml +++ /dev/null @@ -1,145 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of triangles. -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. -type: group -NXcg_triangle(NXcg_primitive): - number_of_unique_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - Number of unique vertices in the triangle set. - triangles(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. - triangleID(NXcg_face_list_data_structure): - nameType: partial - doc: | - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. - dimensions: - rank: 2 - dim: (c, 3) - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. - dimensions: - rank: 2 - dim: (c, 3) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fe99956b8b305e0e920fc7b726b5f8ed243fefa82c6ebb87f13e1ce8cdebef9d -# -# -# -# -# -# -# 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. -# -# -# -# Number of unique vertices in the triangle set. -# -# -# -# -# Combined storage of all primitives of all triangles. -# -# This description resembles the typical representation of primitives -# in file formats such as OFF, PLY, VTK, or STL. -# -# -# -# -# Individual storage of each triangle. -# Users are advised that using such individual storage of primitives -# may be less storage efficient than creating a combined storage. -# -# -# -# -# Length of the edges of each triangle. -# -# For each triangle values are reported via traversing -# the vertices in the sequence as these are defined. -# -# -# -# -# -# -# -# -# Interior angles of each triangle. -# -# For each triangle values are reported for the angle opposite -# to the respective edges in the sequence how vertices are defined. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_unit_normal.yaml b/contributed_definitions/nyaml/NXcg_unit_normal.yaml deleted file mode 100644 index 16e3be34d6..0000000000 --- a/contributed_definitions/nyaml/NXcg_unit_normal.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of (oriented) unit normal vectors. - - Store normal vector information as properties of primitives. - Use only only as a child of an instance of :ref:`NXcg_primitive` - so that this instance acts as the parent to define a context. - -# eventually remove this base class and make normal vector a property of the primitive -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. - -# 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 -type: group -NXcg_unit_normal(NXobject): - normals(NX_NUMBER): - unit: NX_LENGTH - doc: | - Direction of each normal - a unit normal. - dimensions: - rank: 2 - dim: (c, d) - orientation(NX_INT): - unit: NX_UNITLESS - doc: | - An indicator which details the orientation of each normal vector - in relation to its primitive, assuming the object is viewed - from a position outside the object. - - * 0 - undefined - * 1 - outer unit normal vector - * 2 - inner unit normal vector - dimensions: - rank: 1 - dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f987a47e06d87c7a3835affeda661ac97e7939eb67c9775e11698bc408a0b88e -# -# -# -# -# -# -# -# -# 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. -# -# Store normal vector information as properties of primitives. -# Use only only as a child of an instance of :ref:`NXcg_primitive` -# so that this instance acts as the parent to define a context. -# -# -# -# Direction of each normal - a unit normal. -# -# -# -# -# -# -# -# -# An indicator which details the orientation of each normal vector -# in relation to its primitive, assuming the object is viewed -# from a position outside the object. -# -# * 0 - undefined -# * 1 - outer unit normal vector -# * 2 - inner unit normal vector -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml deleted file mode 100644 index 23b89ab311..0000000000 --- a/contributed_definitions/nyaml/NXchemical_composition.yaml +++ /dev/null @@ -1,149 +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. -type: group -NXchemical_composition(NXobject): - normalization(NX_CHAR): - 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 which are of a particular type. - By contrast, weight_percent normalization factorizes in the - respective mass of the elements. Software libraries that work with units - (like pint in Python) are challenged by these differences as at.-% and - wt.-% are both fractional quantities. - enumeration: [atom_percent, weight_percent] - total(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Total based on which composition information is normalized. - dimensions: - rank: 1 - dim: (n,) - ELEMENT(NXatom): - exists: ['min', '1', 'max', '118'] - nameType: any - doc: | - Instances names for groups should use the chemical symbol of - the element as it is defined in the periodic table. - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total yields the composition - of this element, isotope, molecule, or ion. - dimensions: - rank: 1 - dim: (n,) - composition(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Composition value for the element/ion referred to under name. - Composition is reported either normalized for atomic or weight - percent. The field normalization should be used to communicate - this explicitly. Composition should be reported consistently - for all instances ELEMENT. - composition_error(NX_FLOAT): - exists: recommended - unit: NX_DIMENSIONLESS - doc: | - Magnitude of the standard deviation of the composition. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eb5e3d5b6319c316bcb36db7e27a737abf5093e7b405147b483b4c2401780663 -# -# -# -# -# -# -# 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. -# -# -# -# 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 which are of a particular type. -# By contrast, weight_percent normalization factorizes in the -# respective mass of the elements. Software libraries that work with units -# (like pint in Python) are challenged by these differences as at.-% and -# wt.-% are both fractional quantities. -# -# -# -# -# -# -# -# -# Total based on which composition information is normalized. -# -# -# -# -# -# -# -# Instances names for groups should use the chemical symbol of -# the element as it is defined in the periodic table. -# -# -# -# Count or weight which, when divided by total yields the composition -# of this element, isotope, molecule, or ion. -# -# -# -# -# -# -# -# Composition value for the element/ion referred to under name. -# Composition is reported either normalized for atomic or weight -# percent. The field normalization should be used to communicate -# this explicitly. Composition should be reported consistently -# for all instances ELEMENT. -# -# -# -# -# Magnitude of the standard deviation of the composition. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml deleted file mode 100644 index 37a39d2463..0000000000 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ /dev/null @@ -1,272 +0,0 @@ -category: base -doc: | - Base class for documenting circuit devices. - - Electronic circuits are hardware components that connect several electronic components to achieve - specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. -symbols: - doc: | - Constant to be used in the definition: the number of channels of the - circuit board. - N_channel: | - Number of channels of the circuit board. -type: group -NXcircuit(NXcomponent): - hardware(NXfabrication): - doc: | - Hardware where the circuit is implanted; includes information about the - hardware manufacturers and type (e.g. part number) - All the elements below may be single numbers of an array of values with length N_channel - describing multiple input and output channels. - components(NX_CHAR): - doc: | - List of components used in the circuit, e.g., resistors, capacitors, transistors or any - other complex components. - connections(NX_CHAR): - doc: | - Description of how components are interconnected, including connection points - and wiring. - power_source(NX_CHAR): - doc: | - Details of the power source for the circuit, including voltage and current - ratings. - signal_type(NX_CHAR): - doc: | - Type of signal (input signal) the circuit is designed to handle, e.g., analog, - digital, mixed-signal. - - # should this be a min / max range? - operating_frequency(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The operating frequency of the circuit, see also bandwidth, which is possibly - but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth - amplifier at low, audio frequencies 1 - 20,000 Hz). - bandwidth(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The bandwidth of the frequency response of the circuit. - - # we may need an NX_RESISTANCE defined - input_impedance(NX_NUMBER): - unit: NX_ANY - doc: | - Input impedance of the circuit. - output_impedance(NX_NUMBER): - unit: NX_ANY - doc: | - Output impedance of the circuit. - gain(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Gain of the circuit, if applicable, usually all instruments have a gain - which might be important or not. - noise_level(NX_NUMBER): - unit: NX_ANY - doc: | - Root-mean-square (RMS) noise level (in current or voltage) - in the circuit in voltage or current. - temperature_range(NX_NUMBER): - unit: NX_ANY - doc: | - Operating temperature range of the circuit. - calibration(NXcalibration): - doc: | - Calibration data for the circuit. - offset(NX_NUMBER): - unit: NX_ANY - doc: | - Offset value for current or voltage. - output_channels(NX_NUMBER): - doc: | - Number of output channels collected to this circuit. Most probably N_channel. - output_signal(NX_NUMBER): - unit: NX_ANY - doc: | - Type of output signal, e.g., voltage, current, digital. - power_consumption(NX_NUMBER): - unit: NX_ANY - doc: | - Power consumption of the circuit per unit time. - status_indicators(NX_CHAR): - doc: | - Status indicators for the circuit, e.g., LEDs, display readouts. - protection_features(NX_CHAR): - doc: | - Protection features built into the circuit, e.g., overvoltage protection, - thermal shutdown. - acquisition_time(NX_NUMBER): - unit: NX_TIME - doc: | - Updated rate for several processes using the input signal, e.g., History Graph, the circuit - uses for any such process. - output_slew_rate(NX_CHAR): - doc: | - The rate at which the signal changes when ramping from the starting - value. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 618f030e81428fff01c66c2a4af66d1697e51dd87d955b2a63f08628a6c316ff -# -# -# -# -# -# -# Constant to be used in the definition: the number of channels of the -# circuit board. -# -# -# -# Number of channels of the circuit board. -# -# -# -# -# Base class for documenting circuit devices. -# -# Electronic circuits are hardware components that connect several electronic components to achieve -# specific functionality, e.g. amplifying a voltage or convert a voltage to binary numbers, etc. -# -# -# -# Hardware where the circuit is implanted; includes information about the -# hardware manufacturers and type (e.g. part number) -# All the elements below may be single numbers of an array of values with length N_channel -# describing multiple input and output channels. -# -# -# -# -# List of components used in the circuit, e.g., resistors, capacitors, transistors or any -# other complex components. -# -# -# -# -# Description of how components are interconnected, including connection points -# and wiring. -# -# -# -# -# Details of the power source for the circuit, including voltage and current -# ratings. -# -# -# -# -# Type of signal (input signal) the circuit is designed to handle, e.g., analog, -# digital, mixed-signal. -# -# -# -# -# -# The operating frequency of the circuit, see also bandwidth, which is possibly -# but not necessarily centered around this frequency (e.g. running a 100 kHz bandwidth -# amplifier at low, audio frequencies 1 - 20,000 Hz). -# -# -# -# -# The bandwidth of the frequency response of the circuit. -# -# -# -# -# -# Input impedance of the circuit. -# -# -# -# -# Output impedance of the circuit. -# -# -# -# -# Gain of the circuit, if applicable, usually all instruments have a gain -# which might be important or not. -# -# -# -# -# Root-mean-square (RMS) noise level (in current or voltage) -# in the circuit in voltage or current. -# -# -# -# -# Operating temperature range of the circuit. -# -# -# -# -# Calibration data for the circuit. -# -# -# -# -# Offset value for current or voltage. -# -# -# -# -# Number of output channels collected to this circuit. Most probably N_channel. -# -# -# -# -# Type of output signal, e.g., voltage, current, digital. -# -# -# -# -# Power consumption of the circuit per unit time. -# -# -# -# -# Status indicators for the circuit, e.g., LEDs, display readouts. -# -# -# -# -# Protection features built into the circuit, e.g., overvoltage protection, -# thermal shutdown. -# -# -# -# -# Updated rate for several processes using the input signal, e.g., History Graph, the circuit -# uses for any such process. -# -# -# -# -# The rate at which the signal changes when ramping from the starting -# value. -# -# -# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml deleted file mode 100644 index cec7902e3d..0000000000 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ /dev/null @@ -1,303 +0,0 @@ -category: base -doc: | - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different conventions and - models for quantifying the aberration coefficients. - - Correctors in an electron microscope are composed of multiple lenses - and multipole stigmators. Their technical details are specific for the - technology partner as well as microscope. Most technical details are - proprietary knowledge. - - If one component corrects for multiple types of aberrations (like it is the case - reported here `CEOS `_) follow this - design when using corrector and monochromator in an application definition: - - * Use :ref:`NXcorrector_cs` for spherical aberration - * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration - * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_img: | - Number of images taken, at least one. -type: group -NXcorrector_cs(NXcomponent): - - # user perspective - applied(NX_BOOLEAN): - doc: | - Was the corrector used? - tableauID(NXprocess): - nameType: partial - doc: | - Specific information about the alignment procedure. This is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberrations. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details about the alignment - procedure. - tilt_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. Suggestions from the community are - welcome here for guiding an improvement of this base class. - dimensions: - rank: 1 - dim: (n_img,) - exposure_time(NX_NUMBER): - unit: NX_TIME - doc: | - The exposure time of single tilt images. - dimensions: - rank: 1 - dim: (n_img,) - magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The factor of enlargement of the apparent size, - not the physical size, of an object. - dimensions: - rank: 1 - dim: (n_img,) - imageID(NXimage): - nameType: partial - doc: | - Image(s) taken during the alignment procedure - model(NX_CHAR): - doc: | - Convention used for storing measured or estimated aberrations (for each or the final image) - via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. - - 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. Conversion tables are also summarized by `Y. Liao `_. - enumeration: [ceos, nion] - - # specifically-named aberrations following the CEOS / Typke and Dierksen convention - c_1(NXaberration): - a_1(NXaberration): - b_2(NXaberration): - a_2(NXaberration): - c_3(NXaberration): - s_3(NXaberration): - a_3(NXaberration): - - # based on feedback from Thilo Remmele the following aberrations could be measured - # (enhanced mode, tilt angle > 30 mrad) but are not corrected for with - b_4(NXaberration): - d_4(NXaberration): - a_4(NXaberration): - c_5(NXaberration): - s_5(NXaberration): - r_5(NXaberration): - a_6(NXaberration): - - # specifically-named aberrations following the Nion convention - c_1_0(NXaberration): - c_1_2_a(NXaberration): - c_1_2_b(NXaberration): - c_2_1_a(NXaberration): - c_2_1_b(NXaberration): - c_2_3_a(NXaberration): - c_2_3_b(NXaberration): - c_3_0(NXaberration): - c_3_2_a(NXaberration): - c_3_2_b(NXaberration): - c_3_4_a(NXaberration): - c_3_4_b(NXaberration): - c_4_1_a(NXaberration): - c_4_1_b(NXaberration): - c_4_3_a(NXaberration): - c_4_3_b(NXaberration): - c_4_5_a(NXaberration): - c_4_5_b(NXaberration): - c_5_0(NXaberration): - c_5_2_a(NXaberration): - c_5_2_b(NXaberration): - c_5_4_a(NXaberration): - c_5_4_b(NXaberration): - c_5_6_a(NXaberration): - c_5_6_b(NXaberration): - (NXlens_em): - (NXaperture): - (NXdeflector): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6058db5121e6633ea3ec355f79d43ab1ee54bf298dd8945d3f0746dd51a5af33 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of images taken, at least one. -# -# -# -# -# Base class for a corrector reducing (spherical) aberrations in electron microscopy. -# -# Different technology partners use different conventions and -# models for quantifying the aberration coefficients. -# -# Correctors in an electron microscope are composed of multiple lenses -# and multipole stigmators. Their technical details are specific for the -# technology partner as well as microscope. Most technical details are -# proprietary knowledge. -# -# If one component corrects for multiple types of aberrations (like it is the case -# reported here `CEOS <https://www.ceos-gmbh.de/en/research/electrostat>`_) follow this -# design when using corrector and monochromator in an application definition: -# -# * Use :ref:`NXcorrector_cs` for spherical aberration -# * Use :ref:`NXmonochromator` for energy filtering or chromatic aberration -# * Use the group corrector_ax in :ref:`NXem` for axial astigmatism aberration -# -# -# -# -# Was the corrector used? -# -# -# -# -# Specific information about the alignment procedure. This is a process during which -# the corrector is configured to enable calibrated usage of the instrument. -# -# This :ref:`NXprocess` group should also be used when one describes in a computer -# simulation the specific details about the modelled or assumed aberrations. -# -# -# -# Discouraged free-text field to add further details about the alignment -# procedure. -# -# -# -# -# The outer tilt angle of the beam in tableau acquisition. -# -# TODO: The relevant axes which span the tilt_angle need a -# cleaner description. Suggestions from the community are -# welcome here for guiding an improvement of this base class. -# -# -# -# -# -# -# -# The exposure time of single tilt images. -# -# -# -# -# -# -# -# The factor of enlargement of the apparent size, -# not the physical size, of an object. -# -# -# -# -# -# -# -# Image(s) taken during the alignment procedure -# -# -# -# -# Convention used for storing measured or estimated aberrations (for each or the final image) -# via fields c_1, a_1, c_1_0, c_1_2_a, and so on and so forth. -# -# 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. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml deleted file mode 100644 index aa847979ce..0000000000 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ /dev/null @@ -1,87 +0,0 @@ -category: base -doc: | - Base class for reporting the description of a computer -type: group -NXcs_computer(NXobject): - name(NX_CHAR): - doc: | - Given name/alias to the computing system, e.g. MyDesktop. - operating_system(NX_CHAR): - doc: | - Name of the operating system, e.g. Windows, Linux, Mac, Android. - \@version(NX_CHAR): - 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(NX_CHAR): - doc: | - A globally unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - (NXcs_process): - (NXcs_memory): - (NXcs_storage): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8c3423ab012d77662d765c69bbf7280b87d75a6434e336d4951c58ef9174601 -# -# -# -# -# -# Base class for reporting the description of a computer -# -# -# -# Given name/alias to the computing system, e.g. MyDesktop. -# -# -# -# -# Name of the operating system, e.g. Windows, Linux, Mac, Android. -# -# -# -# Version plus build number, commit hash, or description of an ever -# persistent resource where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# -# A globally unique persistent identifier of the computer, i.e. -# the Universally Unique Identifier (UUID) of the computing node. -# -# -# -# -# -# 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 1c252a60cb..0000000000 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ /dev/null @@ -1,193 +0,0 @@ -category: base -doc: | - Base class for packing and unpacking booleans. - - This base class bookkeeps metadata to inform software about necessary modulo - operations to decode e.g. set membership of objects in sets which are encoded - as a packed array of boolean values. - - One use case is processing of object sets (e.g. point cloud data). If e.g. a - spatial filter has been applied to a set of points we may wish to store - document efficiently which points were analyzed. Array of boolean values - is one option to achieve this. A value is true if the point is included. - The resulting boolean array will be filled with true and false values - in a manner that is often arbitrary and in general case-dependent. - - Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one does not store - the boolean array but just lists the identifiers of the points taken. - - For example, if within a set of 1000 points only one point is included, it would - take (naively) 4000 bits to store the array but only 32 bits to store e.g. the - ID of the single point that is taken. 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 in that - they store compact representation of set memberships. - - This base class can deal with the situation when the number of objects - is not an integer multiple of the bit depth used for storing the states. -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. -type: group -NXcs_filter_boolean_mask(NXobject): - depends_on(NX_CHAR): - doc: | - Possibility to refer to which set this mask applies. - - If depends_on is not provided, it is assumed that the mask - applies to its direct parent. - number_of_objects(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of objects represented by the mask. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The content of the mask. If padding is used, - padding bits have to be set to 0. - dimensions: - rank: 1 - dim: (n_total,) - - # - # - # 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. Resolving of identifier follows - # the conventions made for depends_on, so consult also the description - # of th content to which depends_on refers. - # - # - # - # - # - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 409dae974d393935c12b69a9b364560ada6e49c30ad2c74c16d737187e31f690 -# -# -# -# -# -# -# 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. -# -# -# -# -# Base class for packing and unpacking booleans. -# -# This base class bookkeeps metadata to inform software about necessary modulo -# operations to decode e.g. set membership of objects in sets which are encoded -# as a packed array of boolean values. -# -# One use case is processing of object sets (e.g. point cloud data). If e.g. a -# spatial filter has been applied to a set of points we may wish to store -# document efficiently which points were analyzed. Array of boolean values -# is one option to achieve this. A value is true if the point is included. -# The resulting boolean array will be filled with true and false values -# in a manner that is often arbitrary and in general case-dependent. -# -# Especially when the number of points is large, for instance several thousands -# or more, some situations can be more efficiently stored if one does not store -# the boolean array but just lists the identifiers of the points taken. -# -# For example, if within a set of 1000 points only one point is included, it would -# take (naively) 4000 bits to store the array but only 32 bits to store e.g. the -# ID of the single point that is taken. 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 in that -# they store compact representation of set memberships. -# -# This base class can deal with the situation when the number of objects -# is not an integer multiple of the bit depth used for storing the states. -# -# -# -# Possibility to refer to which set this mask applies. -# -# If depends_on is not provided, it is assumed that the mask -# applies to its direct parent. -# -# -# -# -# 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 content of the mask. If padding is used, -# padding bits have to be set to 0. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_memory.yaml b/contributed_definitions/nyaml/NXcs_memory.yaml deleted file mode 100644 index 7ab7fbae04..0000000000 --- a/contributed_definitions/nyaml/NXcs_memory.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for reporting the description of the memory system of a computer. -type: group -NXcs_memory(NXcomponent): - (NXcircuit): - type(NX_CHAR): - doc: | - Qualifier for the type of random access memory. - enumeration: - open_enum: true - items: [ddr4, ddr5] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 03f38cfd71b4b756cf9fc6db35a038a594dde358af5da47d2b5ce3737ca1bd80 -# -# -# -# -# -# Base class for reporting the description of the memory system of a computer. -# -# -# -# -# Qualifier for the type of random access memory. -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml deleted file mode 100644 index 6c37e92220..0000000000 --- a/contributed_definitions/nyaml/NXcs_prng.yaml +++ /dev/null @@ -1,134 +0,0 @@ -category: base -doc: | - Computer science description of pseudo-random number generator. - - The purpose of this base class 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. -type: group -NXcs_prng(NXobject): - type(NX_CHAR): - doc: | - Physical approach or algorithm whereby random numbers are generated. - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device whose the state is unpredictable - (physically). Some use a strategy of mangling information from the system - clock. Also in this case the sequence is not reproducible without having - additional pieces of information. - - In most cases though so-called pseudo-random number generator (PRNG) - algorithms are used. These yield a deterministic sequence of practically - randomly appearing numbers. These algorithms differ in their quality in - how close the resulting sequences are random, i.e. sequentially - uncorrelated. Nowadays one of the most commonly used algorithm is the - MersenneTwister (mt19937). - enumeration: [physical, system_clock, mt19937, other] - (NXprogram): - 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. - seed(NX_INT): - unit: NX_UNITLESS - doc: | - Parameter of the PRNG controlling its initialization - and thus controlling the specific sequence generated. - warmup(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of initial draws from the PRNG after its initialized with the seed. - These initial draws are typically discarded in an effort to equilibrate the - sequence. If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - # 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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7cab5bbba4affc39c86fe740226d4ce392527678c47a47e1c18f37157aaba203 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of pseudo-random number generator. -# -# The purpose of this base class is to identify if exactly the same sequence -# can be reproduced, like for a PRNG or not (for a true physically random source). -# -# -# -# Physical approach or algorithm whereby random numbers are generated. -# -# Different approaches for generating random numbers with a computer exists. -# Some use a dedicated physical device whose the state is unpredictable -# (physically). Some use a strategy of mangling information from the system -# clock. Also in this case the sequence is not reproducible without having -# additional pieces of information. -# -# In most cases though so-called pseudo-random number generator (PRNG) -# algorithms are used. These yield a deterministic sequence of practically -# randomly appearing numbers. These algorithms differ in their quality in -# how close the resulting sequences are random, i.e. sequentially -# uncorrelated. 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. -# -# -# -# -# Parameter of the PRNG controlling its initialization -# and thus controlling the specific sequence generated. -# -# -# -# -# Number of initial draws from the PRNG after its initialized with the seed. -# These initial draws are typically discarded in an effort to equilibrate the -# sequence. 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_process.yaml b/contributed_definitions/nyaml/NXcs_process.yaml deleted file mode 100644 index c2d372aa08..0000000000 --- a/contributed_definitions/nyaml/NXcs_process.yaml +++ /dev/null @@ -1,78 +0,0 @@ -category: base -doc: | - Base class for reporting the description of processing units of a computer. - - Examples are e.g. (classical) processing units (CPUs), coprocessor, - graphic cards, accelerator processing units or a system of these. -type: group -NXcs_process(NXcomponent): - (NXcircuit): - doc: | - Typical examples for the granularization of processing units are: - - * A desktop computer with a single CPU; describe using one instance of NXcircuit. - * A dual-socket server; describe using two instances of NXcircuit. - * A server with two dual-socket server nodes; describe with four - instances of NXcircuit surplus a field that defines their level - in the hierarchy. - type(NX_CHAR): - doc: | - General type of the processing unit - enumeration: - open_enum: true - items: [cpu, gpu, fpga] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e63846fc37f720e00d319289435e1f4f1869f2632b2c0db2ebe3196dcad64689 -# -# -# -# -# -# Base class for reporting the description of processing units of a computer. -# -# Examples are e.g. (classical) processing units (CPUs), coprocessor, -# graphic cards, accelerator processing units or a system of these. -# -# -# -# Typical examples for the granularization of processing units are: -# -# * A desktop computer with a single CPU; describe using one instance of NXcircuit. -# * A dual-socket server; describe using two instances of NXcircuit. -# * A server with two dual-socket server nodes; describe with four -# instances of NXcircuit surplus a field that defines their level -# in the hierarchy. -# -# -# -# General type of the processing unit -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml deleted file mode 100644 index 9139a48cdd..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ /dev/null @@ -1,263 +0,0 @@ -category: base -doc: | - Computer science description for performance and profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - 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 and these are used usually by multiple users. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app) took. - A frequent idea is here to answer practical questions like how critical is the - effect on the workflow of the scientists, i.e. is the analysis possible in - a few seconds or would it take days if I were to run this analysis on a - comparable machine? - For this more qualitative performance monitoring, mainly the order of - magnitude is relevant, as well as how this was achieved using parallelization - (i.e. reporting the number of CPU and GPU resources used, the number of - processes and threads configured, and providing basic details about the computer). - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks; in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization, i.e. by software and hardware developers as well as for - tracking bugs. Specialized software exists which documents such performance - data in specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions for now. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - 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. -type: group -NXcs_profiling(NXobject): - - # details about queuing systems etc - current_working_directory(NX_CHAR): - doc: | - Path to the directory from which the tool was called. - 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): - unit: NX_TIME - 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 demands a more precise record of the wall-clock time. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field e.g. for apps which use e.g. MPI - (Message Passing Interface) parallelization is to communicate - how many processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - 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. - number_of_threads(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how many nominal threads were used at runtime. - Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - number_of_gpus(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier with how many nominal GPUs the app was invoked at runtime. - - # 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. - (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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0cc01f57e0b4c276a9ee507e7846b5410ffcdfb2656444a03d8aa447e41931a1 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description for performance and profiling data of an application. -# -# Performance monitoring and benchmarking of software is a task where questions -# can be asked at various levels of detail. In general, there are three main -# 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 and these are used usually by multiple users. -# -# At the most basic level users may wish to document how long e.g. a data -# analysis with a scientific software (app) took. -# A frequent idea is here to answer practical questions like how critical is the -# effect on the workflow of the scientists, i.e. is the analysis possible in -# a few seconds or would it take days if I were to run this analysis on a -# comparable machine? -# For this more qualitative performance monitoring, mainly the order of -# magnitude is relevant, as well as how this was achieved using parallelization -# (i.e. reporting the number of CPU and GPU resources used, the number of -# processes and threads configured, and providing basic details about the computer). -# -# At more advanced levels benchmarks may go as deep as detailed temporal tracking -# of individual processor instructions, their relation to other instructions, the -# state of call stacks; in short eventually the entire app execution history -# and hardware state history. Such analyses are mainly used for performance -# optimization, i.e. by software and hardware developers as well as for -# tracking bugs. Specialized software exists which documents such performance -# data in specifically-formatted event log files or databases. -# -# This base class cannot and should not replace these specific solutions for now. -# Instead, the intention of the base class is to serve scientists at the -# basic level to enable simple monitoring of performance data and log profiling -# data of key algorithmic steps or parts of computational workflows, so that -# these pieces of information can guide users which order of magnitude differences -# 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 demands a more precise record of the wall-clock time. -# -# -# -# -# Qualifier which specifies with how many nominal processes the app was -# invoked. The main idea behind this field e.g. for apps which use e.g. MPI -# (Message Passing Interface) parallelization is to communicate -# how many processes were used. -# -# For sequentially running apps number_of_processes and number_of_threads -# is 1. If the app uses exclusively GPU parallelization number_of_gpus -# 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 how many nominal threads were used at runtime. -# Specifically here the maximum number of threads used for the -# high-level threading library used (e.g. OMP_NUM_THREADS), posix. -# -# -# -# -# Qualifier with how many nominal GPUs the app was invoked at runtime. -# -# -# -# -# -# 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.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml deleted file mode 100644 index 4180253a8c..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling_event.yaml +++ /dev/null @@ -1,159 +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. -type: group -NXcs_profiling_event(NXobject): - 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(NX_CHAR): - doc: | - Free-text description what was monitored/executed during the event. - elapsed_time(NX_NUMBER): - unit: NX_TIME - 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 for a more precise record of the - wall-clock time. - - Elapsed time may contain time portions where resources were idling. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of processes used (max) during the execution of this event. - number_of_threads(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of threads used (max) during the execution of this event. - number_of_gpus(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of GPUs used (max) during the execution of this event. - max_virtual_memory_snapshot(NX_NUMBER): - unit: NX_ANY - doc: | - Maximum amount of virtual memory allocated per process during the event. - dimensions: - rank: 1 - dim: (n_processes,) - max_resident_memory_snapshot(NX_NUMBER): - unit: NX_ANY - doc: | - Maximum amount of resident memory allocated per process during the event. - dimensions: - rank: 1 - dim: (n_processes,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d783e6ceae7d0db339dd1ef0edea44e0faf6443c8b665d23c7a06ea9ad055c73 -# -# -# -# -# -# -# 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 for a more precise record of the -# wall-clock time. -# -# Elapsed time may contain time portions where resources were idling. -# -# -# -# -# Number of processes used (max) during the execution of this event. -# -# -# -# -# Number of threads used (max) during the execution of this event. -# -# -# -# -# Number of GPUs used (max) during the execution of this event. -# -# -# -# -# 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/NXcs_storage.yaml b/contributed_definitions/nyaml/NXcs_storage.yaml deleted file mode 100644 index e11360165c..0000000000 --- a/contributed_definitions/nyaml/NXcs_storage.yaml +++ /dev/null @@ -1,62 +0,0 @@ -category: base -doc: | - Base class for reporting the description of the I/O of a computer. -type: group -NXcs_storage(NXcomponent): - (NXcircuit): - type(NX_CHAR): - doc: | - Qualifier for the type of storage medium used. - enumeration: [solid_state_disk, hard_disk, tape] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 23d6eaded2f856c501322359c37f1cf51f34300d2feed62f65334296a430b5c5 -# -# -# -# -# -# Base class for reporting the description of the I/O of a computer. -# -# -# -# -# Qualifier for the type of storage medium used. -# -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml deleted file mode 100644 index 332e38c405..0000000000 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ /dev/null @@ -1,428 +0,0 @@ -category: base -doc: | - Base class for a set of components providing a controllable electron beam. - - The idea behind defining NXebeam_column as an own base class vs. adding these - concepts in NXinstrument_em is that the electron beam generating component - might be worthwhile to use also in other types of experiments. -type: group -NXebeam_column(NXcomponent): - operation_mode(NX_CHAR): - doc: | - Tech-partner, microscope-, and control-software-specific name of the - specific operation mode how the ebeam_column and its components are - controlled to achieve specific illumination conditions. - - In many cases the users of an instrument do not or can not be expected to know - all intricate spatiotemporal dynamics of their hardware. Instead, they rely on - assumptions that the instrument, its control software, and components work as - expected to focus on their research questions. - - For these cases, having a place for documenting the operation_mode is useful - in as much as at least some constraints on how the illumination conditions were - is documented. - electron_source(NXsource): - doc: - - | - A physical part of an electron or ion microscope from which - the particles that form the beam are emitted. - - | - The hardware for an electron source in an electron microscope - may contain several components which affect the beam path. - - | - xref: - spec: EMglossary - term: Source - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: - - | - The potential difference between anode and cathode. - - | - xref: - spec: EMglossary - term: Acceleration Voltage - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - extraction_voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: - - | - Voltage which is used to create an electric field that draws particles from - the source. - - | - xref: - spec: EMglossary - term: Extraction Voltage - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - emission_current(NX_NUMBER): - unit: NX_CURRENT - doc: - - | - Electrical current which is released from the source. - - | - xref: - spec: EMglossary - term: Emission Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - filament_current(NX_NUMBER): - unit: NX_CURRENT - doc: - - | - Electrical current which flows through the source. - - | - xref: - spec: EMglossary - term: Filament Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - probe(NX_CHAR): - doc: | - Type of radiation. - enumeration: [electron] - emitter_type(NX_CHAR): - 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(NX_CHAR): - doc: | - Material of which the emitter is build, e.g. the filament material. - - # emitter material could inherit from NXsample - lifetime(NX_NUMBER): - unit: NX_TIME - doc: | - How long has the source been in operation. - (NXlens_em): - (NXaperture): - (NXdeflector): - blankerID(NXdeflector): - nameType: partial - doc: | - A component for blanking the beam or generating pulsed electron beams. - See e.g . `I. G. C. Weppelman et al. `_ - or `Y. Liao `_ for details. - (NXmonochromator): - doc: | - Device to improve energy resolution or chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like `_ - - # control level perspective - type(NX_CHAR): - doc: | - Qualitative type of the component. - enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] - (NXfabrication): - applied(NX_BOOLEAN): - doc: | - Was the corrector used? - - # technical level - dispersion(NX_NUMBER): - unit: NX_ANY - doc: | - Energy dispersion in e.g. µm/eV. - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Corresponding voltage for that energy dispersion. - corrector_cs(NXcorrector_cs): - corrector_ax(NXcomponent): - doc: | - Component that reshapes an ellipse-shaped electron beam into a circular one. - - * `L. Reimer 1998, Springer, 1998 `_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - Stigmator is an exact synonym. - value_x(NX_NUMBER): - unit: NX_ANY - 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 users. - value_y(NX_NUMBER): - unit: NX_ANY - 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 users. - biprismID(NXcomponent): - nameType: partial - doc: | - Electron biprism as it is used e.g. for electron holography. - phaseplateID(NXcomponent): - nameType: partial - doc: | - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. `_ - * `R. R. Schröder et al. `_ - type(NX_CHAR): - doc: | - Qualitative type - enumeration: - open_enum: true - items: [thin_film, electrostatic] - (NXsensor): - (NXactuator): - (NXbeam): - doc: - - | - Individual characterization results for the position, shape, - and characteristics of the electron beam at a given location. - - | - :ref:`NXtransformations` should be used to specify the location - or the position at which details about the beam were probed. - - | - xref: - spec: EMglossary - term: Electron Beam - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - (NXcomponent): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1a0b8cfa31f7ddb34bf2c8001383fd77768103af9b0be227befcde88466d3c8e -# -# -# -# -# -# Base class for a set of components providing a controllable electron beam. -# -# The idea behind defining NXebeam_column as an own base class vs. adding these -# concepts in NXinstrument_em is that the electron beam generating component -# might be worthwhile to use also in other types of experiments. -# -# -# -# Tech-partner, microscope-, and control-software-specific name of the -# specific operation mode how the ebeam_column and its components are -# controlled to achieve specific illumination conditions. -# -# In many cases the users of an instrument do not or can not be expected to know -# all intricate spatiotemporal dynamics of their hardware. Instead, they rely on -# assumptions that the instrument, its control software, and components work as -# expected to focus on their research questions. -# -# For these cases, having a place for documenting the operation_mode is useful -# in as much as at least some constraints on how the illumination conditions were -# is documented. -# -# -# -# -# A physical part of an electron or ion microscope from which -# the particles that form the beam are emitted. -# -# The hardware for an electron source in an electron microscope -# may contain several components which affect the beam path. -# -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 -# -# -# -# The potential difference between anode and cathode. -# -# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. -# -# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 -# -# -# -# -# Voltage which is used to create an electric field that draws particles from -# the source. -# -# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. -# -# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which is released from the source. -# -# This concept is related to term `Emission Current`_ of the EMglossary standard. -# -# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which flows through the source. -# -# This concept is related to term `Filament Current`_ of the EMglossary standard. -# -# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 -# -# -# -# -# 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. -# -# -# -# -# -# How long has the source been in operation. -# -# -# -# -# -# -# -# -# A component for blanking the beam or generating pulsed electron beams. -# See e.g . `I. G. C. Weppelman et al. <https://doi.org/10.1016/j.ultramic.2017.10.002>`_ -# or `Y. Liao <https://www.globalsino.com/EM/page2464.html>`_ for details. -# -# -# -# -# Device to improve energy resolution or chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ -# -# -# -# -# Qualitative type of the component. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Was the corrector used? -# -# -# -# -# -# Energy dispersion in e.g. µm/eV. -# -# -# -# -# Corresponding voltage for that energy dispersion. -# -# -# -# -# -# -# Component that reshapes an ellipse-shaped electron beam into a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. -# -# -# -# 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 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 users. -# -# -# -# -# -# Electron biprism as it is used e.g. for electron holography. -# -# -# -# -# Device that causes a change in the phase of an electron wave. -# -# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ -# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ -# -# -# -# Qualitative type -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the electron beam at a given location. -# -# :ref:`NXtransformations` should be used to specify the location -# or the position at which details about the beam were probed. -# -# This concept is related to term `Electron Beam`_ of the EMglossary standard. -# -# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 -# -# -# -# diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml deleted file mode 100644 index a9604f432a..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ /dev/null @@ -1,701 +0,0 @@ -category: application -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 specializes :ref:`NXoptical_spectroscopy` by - extending the terms and setting specific requirements. - - 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 or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - 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. - -# 04/2024 -# A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry. -# 09/2024 -# TODO (Workshop output): -# - Better categorization of ellipsometer types: -# Separate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense) -# Maybe make a given special field for "spectral_range" with units of eV or nm? -# - Add a StepScanAnalzer as measurement type (continuous/rotating mode the other? Ask Chris) -# - Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization. -# - Refinements for ellipsometer_type and add ellipsometer_method/mode: -# "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc). -# ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer", "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer" " -# - Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions -# Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus. -# This explicitly refers to a wish to add: "exposure time, number of scans" -type: group -NXellipsometry(NXoptical_spectroscopy): - (NXentry): - 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] - title: - exists: recommended - experiment_type: - doc: | - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - enumeration: [ellipsometry] - ellipsometry_experiment_type: - doc: | - Specify the type of ellipsometry. - enumeration: - open_enum: true - items: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry] - (NXinstrument): - doc: | - Properties of the ellipsometry equipment. - ellipsometer_type: - doc: | - What type of ellipsometry was used? See Fujiwara Table 4.2. - enumeration: - open_enum: true - items: [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] - focusing_probes(NXoptical_lens): - exists: optional - doc: | - If focusing probes (lenses) were used, please state if the data - were corrected for the window effects. - type: - enumeration: - open_enum: true - items: [objective, lens, glass fiber, none] - device_information(NXfabrication): - exists: optional - data_correction(NX_BOOLEAN): - exists: recommended - doc: | - Were the recorded data corrected by the window effects of the - focusing probes (lenses)? - angular_spread(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Specify the angular spread caused by the focusing probes. - rotating_element(NXwaveplate): - doc: | - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - 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)] - revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - 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. - fixed_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - 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). - max_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Specify the maximum value of revolutions of the rotating element - for each measurement. - (NXsample): - backside_roughness(NX_BOOLEAN): - exists: optional - doc: | - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - data_collection(NXdata): - exists: optional - doc: | - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better - directly in the location of the sample positioner or temperature sensor. - data_identifier(NX_NUMBER): - exists: recommended - 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: - exists: recommended - 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): - nameType: partial - exists: optional - unit: NX_ANY - 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. - dimensions: - rank: 1 - dim: (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): - unit: NX_ANY - 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. - dimensions: - rank: 3 - dim: (N_measurements, N_observables, 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 - unit: NX_ANY - doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - dimensions: - rank: 3 - dim: (N_measurements, N_observables, 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: (N_sensors,) - reference_data_link: - exists: optional - doc: | - :ref:`External link ` to the data field in 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. - - Ideally, the link uses the relative path with respect to the actual - NeXus file. - data_software(NXprogram): - exists: optional - program: - exists: recommended - 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: - exists: recommended - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ed62540ae1100127dc375d0ba9c12c02afad440ef2a38f723704cebb398facd8 -# -# -# -# -# -# -# -# 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 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. -# -# -# -# -# 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 specializes :ref:`NXoptical_spectroscopy` by -# extending the terms and setting specific requirements. -# -# 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 -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# Specify the type of the optical experiment. -# -# You may specify fundamental characteristics or properties in the experimental sub-type. -# -# -# -# -# -# -# -# Specify the type of ellipsometry. -# -# -# -# -# -# -# -# -# -# -# -# -# Properties of the ellipsometry equipment. -# -# -# -# What type of ellipsometry was used? See Fujiwara Table 4.2. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If focusing probes (lenses) were used, please state if the data -# were corrected for the window effects. -# -# -# -# -# -# -# -# -# -# -# -# -# Were the recorded data corrected by the window effects of the -# focusing probes (lenses)? -# -# -# -# -# Specify the angular spread caused by the focusing probes. -# -# -# -# -# -# Properties of the rotating element defined in -# 'instrument/rotating_element_type'. -# -# -# -# Define which element rotates, e.g. polarizer or analyzer. -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Was the backside of the sample roughened? Relevant for infrared -# ellipsometry. -# -# -# -# -# -# Measured data, data errors, and varied parameters. This may be used to describe -# indirectly derived data or data transformed between different descriptions, -# such as: -# Raw Data --> Psi -# Delta Psi, Delta --> N,C,S -# Mueller matrix --> N,C,S -# Mueller matrix --> Psi, Delta -# etc. -# -# Other types of data, such as temperature or sample location, may be saved -# in a generic (NXdata) concept from :ref:`NXoptical_spectroscopy`, or better -# directly in the location of the sample positioner or temperature sensor. -# -# -# -# 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). -# -# -# -# -# -# -# -# :ref:`External link <Design-Links>` to the data field in 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. -# -# Ideally, the link uses the relative path with respect to the actual -# NeXus file. -# -# -# -# -# -# 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. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml deleted file mode 100644 index 827ce7f022..0000000000 --- a/contributed_definitions/nyaml/NXem.yaml +++ /dev/null @@ -1,3177 +0,0 @@ -category: application -doc: | - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive, general description for the - standardization of data and metadata collected using electron microscopy. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used to study electron-beam matter interactions, explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. -type: group -NXem(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - definition(NX_CHAR): - enumeration: [NXem] - profiling(NXcs_profiling): - exists: optional - doc: | - The configuration of the software that was used to generate this NeXus file. - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - A collection of all programs and libraries used to generate this NeXus file. - Ideally, this would enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific set - of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - Instances can also be used to document the modules and libraries that - are offered by the computational environment such as those parsed - from conda or python virtualenv environments. - program(NX_CHAR): - \@version(NX_CHAR): - identifier_experiment(NX_CHAR): - exists: optional - doc: | - A (globally) unique persistent identifier for referring to this experiment. - experiment_alias(NX_CHAR): - exists: optional - doc: | - Alias (short name) which scientists can use to refer to this experiment. - experiment_description(NX_CHAR): - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the field. - 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 - use this start_time field. - - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even using only start_time and end_time - may not be sufficient to infer how long the experiment took or for how long - data were acquired. To bookkeep more fine-grained timestamps over the - course of the experiment is possible with start_time and end_time fields - of respective :ref:`NXevent_data_em` instances. - 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. - - See docstring of the start_time field to see how to use the - start_time and end_time together. - citeID(NXcite): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - noteID(NXnote): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - doc: | - Collection of serialized resources associated with the experiment. - Examples of such resources are files which are formatted using proprietary - data models of technology partners as those generated by the control software - of the microscope during the instrument session. - type(NX_CHAR): - exists: recommended - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - doc: | - Information about persons who performed or were involved in the microscope - session or simulation run. - identifierNAME(NX_CHAR): - nameType: partial - exists: recommended - \@type(NX_CHAR): - name(NX_CHAR): - exists: optional - doc: | - Given (first) name and surname. - affiliation(NX_CHAR): - exists: optional - doc: | - Name of the affiliation at the point in time when the experiment was performed. - address(NX_CHAR): - exists: optional - doc: | - Postal address of the affiliation. - email(NX_CHAR): - exists: optional - doc: | - Email address at the point in time when the experiment was performed. - - Writing the most permanently used email is recommended. - telephone_number(NX_CHAR): - exists: optional - doc: | - Telephone number at the point in time when the experiment was performed. - role(NX_CHAR): - exists: optional - doc: | - User role at the point in time when the experiment was performed. - - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. - sampleID(NXsample): - exists: ['min', '1', 'max', 'unbounded'] - nameType: partial - doc: - - | - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. - Samples can be real or virtual ones as annotated via is_simulation. - - | - The suggested best practice is to call this group sample. In those cases when - multiple samples need to be grouped inside one entry, these SAMPLE groups - should be named using the prefix sample followed an index starting from 1, i.e. - (sample1, sample2). - - | - There are at least two strategies how to store (meta)data when one analyzes multiple - samples - not different ROIs on a single sample though - in one session. - - | - One strategy is to store each sample and its results under an own NXem/ENTRY. - This is one of the most frequent use cases as during most sessions typically only a - single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. - - | - If multiple samples are investigated storing each of them in their own ENTRY group eventually will - demand unnecessary duplication of instrument details. - - | - This can be avoided by using another strategy for storing samples and their results. - Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, - like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., - i.e. instances should use sample as a name prefix. - - | - In this case the collection of events should use identifier_sample to state clearly for which - of the samples loaded the (characterization) event was detected. - - | - xref: - spec: EMglossary - term: Specimen - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - is_simulation(NX_BOOLEAN): - doc: | - Qualifier whether the sample is a real (in which case is_simulation should be set to false) - or a virtual one (in which case is_simulation should be set to true). - physical_form: - exists: recommended - enumeration: - open_enum: true - items: [bulk, foil, thin_film, powder] - identifier_sample(NX_CHAR): - exists: recommended - doc: | - Ideally, (globally) unique persistent identifier which distinguishes this sample from all others - and especially the predecessor/origin from where that sample was cut off. An example of cutting off - is a steel sheet that is the parent sample from which a small portion was wire-eroded that - represents the sample that was then prepared for characterization with an electron microscope. - - The terms sample and specimen are here considered as exact synonyms. - - This field must not be used for an alias for the sample name. Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to identifier_parent. - \@type(NX_CHAR): - identifier_parent(NX_CHAR): - exists: recommended - doc: | - Identifier of the sample from which the sample was cut off or the string *None*. - I.e. the parent to this sample. - - The purpose of this field is to support functionalities for tracking - sample provenance in a research data management system. - \@type(NX_CHAR): - 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 timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - identifier_parent. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for material that is sensitive to the environment such as specimens that were - charged with fast diffusing elements or short-lived radioactive tracers. - - Additional time stamps prior to preparation_date are better placed in resources which - describe but do not pollute the description here with prose. Resolving these - connected metadata is considered the responsibility of the research data management - system and not the a NeXus file. - name(NX_CHAR): - exists: recommended - doc: | - Specimen name - atom_types(NX_CHAR): - 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 research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by identifier_parent or walk through eventually deeply nested groups in - individual data instances. - thickness(NX_NUMBER): - exists: optional - unit: NX_LENGTH - 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 typically 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. - density(NX_NUMBER): - exists: optional - unit: NX_ANY - 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 a - region-of-interest connected to individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details. - description(NX_CHAR): - exists: optional - doc: | - Discouraged free-text field to provide further detail. - consistent_rotations(NXparameters): - exists: recommended - doc: | - The conventions used when reporting crystal orientations. - We follow the best practices of the Material Science community - that are defined in reference ``_. - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin. - This is in accordance with convention 2 of reference ``_. - - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation according to convention 3 - of reference ``_. - enumeration: [passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of reference ``_. - - The most frequently used convention in Materials Science is zxz, which is based on the work - of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished - from (improper) Tait-Bryan angles. - enumeration: [zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of reference ``_. - enumeration: [rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of reference ``_. - enumeration: [p_plus_one, p_minus_one] - VARIADIC_reference_frame(NXcoordinate_system): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - origin(NX_CHAR): - exists: recommended - x(NX_NUMBER): - x_direction(NX_CHAR): - exists: recommended - y(NX_NUMBER): - y_direction(NX_CHAR): - exists: recommended - z(NX_NUMBER): - z_direction(NX_CHAR): - exists: recommended - processing_reference_frame(NXcoordinate_system): - exists: recommended - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the processing_reference_frame. - - It is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: - open_enum: true - items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x(NX_NUMBER): - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - y(NX_NUMBER): - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - z(NX_NUMBER): - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - sample_reference_frame(NXcoordinate_system): - exists: recommended - depends_on(NX_CHAR): - exists: optional - doc: | - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the sample_reference_frame. - - It is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: - open_enum: true - items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x(NX_NUMBER): - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - y(NX_NUMBER): - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - z(NX_NUMBER): - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - detector_reference_frameID(NXcoordinate_system): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - doc: | - The reference frame that is defined by a specific detector. - depends_on(NX_CHAR): - exists: optional - doc: | - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: - open_enum: true - items: [front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x(NX_NUMBER): - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - y(NX_NUMBER): - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - z(NX_NUMBER): - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. - enumeration: - open_enum: true - items: [north, east, south, west, in, out] - measurement(NXem_measurement): - exists: optional - - # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em - instrument(NXinstrument_em): - name(NX_CHAR): - exists: recommended - location(NX_CHAR): - exists: recommended - type(NX_CHAR): - exists: recommended - fabrication(NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - programID(NXprogram): - exists: recommended - nameType: partial - doc: | - Details about the control program used for operating the microscope. - program(NX_CHAR): - \@version(NX_CHAR): - ebeam_column(NXebeam_column): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - electron_source(NXsource): - exists: recommended - emitter_type(NX_CHAR): - probe(NX_CHAR): - exists: optional - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - lensID(NXlens_em): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - apertureID(NXaperture): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - monochromatorID(NXmonochromator): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - type(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - corrector_csID(NXcorrector_cs): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - doc: | - A spherical aberration corrector is a typical component in a transmission electron microscope. - Many instruments have only one, in this case the variadic suffix should be dropped. - If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, - corrector_cs2. - name(NX_CHAR): - exists: recommended - doc: | - Use specifically when there are multiple instances. - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - corrector_ax(NXcomponent): - exists: ['min', '0', 'max', '1'] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - biprismID(NXcomponent): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - phaseplateID(NXcomponent): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - type(NX_CHAR): - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - beamID(NXbeam): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - deflectorID(NXdeflector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - ibeam_column(NXibeam_column): - exists: ['min', '0', 'max', '1'] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - ion_source(NXsource): - emitter_type(NX_CHAR): - probe(NXion): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - lensID(NXlens_em): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - apertureID(NXaperture): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - monochromatorID(NXmonochromator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - type(NX_CHAR): - name(NX_CHAR): - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - - # device for correcting axial astigmatism of ion beam? - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - beamID(NXbeam): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - deflectorID(NXdeflector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - detectorID(NXdetector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - name(NX_CHAR): - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - scan_controller(NXscanbox_em): - exists: optional - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - stageID(NXmanipulator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - design(NX_CHAR): - exists: recommended - - # add enumeration values from old NXstage_lab - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - nanoprobeID(NXmanipulator): - nameType: partial - exists: optional - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - exists: recommended - pumpID(NXpump): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - design(NX_CHAR): - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - eventID(NXevent_data_em): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - identifier_sample(NX_CHAR): - exists: recommended - - # above field is another example for lacking support to define conditional existence constraints - imageID(NXimage): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - (NXprocess): - exists: recommended - input(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - context(NX_CHAR): - detector_identifier(NX_CHAR): - image_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): - exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): - exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - indices_group(NX_INT): - exists: optional - \@long_name(NX_CHAR): - indices_image(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - spectrumID(NXspectrum): - exists: ['min', '0', 'max', 'unbounded'] - nameType: partial - (NXprocess): - exists: recommended - input(NXnote): - exists: recommended - type(NX_CHAR): - file_name(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - context(NX_CHAR): - detector_identifier(NX_CHAR): - spectrum_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - indices_spectrum(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - instrument(NXinstrument_em): - exists: recommended - ebeam_column(NXebeam_column): - operation_mode(NX_CHAR): - electron_source(NXsource): - exists: optional - voltage(NX_NUMBER): - extraction_voltage(NX_NUMBER): - exists: optional - emission_current(NX_NUMBER): - exists: optional - filament_current(NX_NUMBER): - exists: optional - lensID(NXlens_em): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - power_setting(NX_CHAR_OR_NUMBER): - apertureID(NXaperture): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - setting(NX_CHAR_OR_NUMBER): - exists: recommended - doc: | - Descriptor for the aperture setting 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 users. - - # NXaperture/size can be used as a fallback - monochromatorID(NXmonochromator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - applied(NX_BOOLEAN): - dispersion(NX_NUMBER): - exists: recommended - voltage(NX_NUMBER): - exists: recommended - corrector_csID(NXcorrector_cs): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - applied(NX_BOOLEAN): - exists: recommended - tableauID(NXprocess): - nameType: partial - exists: ['min', '1', 'max', 'unbounded'] - - # model(NX_CHAR): - - # ceos - c_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - d_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - r_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_6(NXaberration): - exists: optional - magnitude(NX_NUMBER): - - # nion - c_1_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - - # we could write down how to store the aberrations but we should not force to add aberrations - # basically optional use of NXaberration therein at least some value required - corrector_ax(NXcomponent): - exists: ['min', '0', 'max', '1'] - applied(NX_BOOLEAN): - value_x(NX_NUMBER): - value_y(NX_NUMBER): - - # biprism(NXcomponent): - - # phaseplateID(NXcomponent): - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - beamID(NXbeam): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - deflectorID(NXdeflector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - ibeam_column(NXibeam_column): - exists: ['min', '0', 'max', '1'] - ion_source(NXsource): - probe(NXatom): - voltage(NX_NUMBER): - flux(NX_NUMBER): - lensID(NXlens_em): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - power_setting(NX_CHAR_OR_NUMBER): - apertureID(NXaperture): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - setting(NX_CHAR_OR_NUMBER): - doc: | - Descriptor for the aperture setting 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 users. - monochromatorID(NXmonochromator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - applied(NX_BOOLEAN): - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - beamID(NXbeam): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - deflectorID(NXdeflector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - detectorID(NXdetector): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - mode(NX_CHAR): - doc: | - Operation mode of the detector as displayed by the control software. - scan_controller(NXscanbox_em): - exists: optional - scan_schema(NX_CHAR): - dwell_time(NX_NUMBER): - sensorID(NXsensor): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - actuatorID(NXactuator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - stageID(NXmanipulator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - design(NX_CHAR): - exists: recommended - tilt1(NX_NUMBER): - tilt2(NX_NUMBER): - rotation(NX_NUMBER): - position(NX_NUMBER): - sample_heater(NXactuator): - exists: optional - physical_quantity(NX_CHAR): - heater_current(NX_NUMBER): - exists: optional - unit: NX_CURRENT - doc: | - Nominal current of the heater. - heater_voltage(NX_NUMBER): - exists: optional - unit: NX_VOLTAGE - doc: | - Nominal voltage of the heater. - heater_power(NX_NUMBER): - unit: NX_POWER - nanoprobeID(NXmanipulator): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - optics(NXoptical_system_em): - exists: recommended - simulation(NXem_simulation): - exists: optional - doc: | - Documentation for a simulation of electron beam-matter interaction. - programID(NXprogram): - nameType: partial - exists: recommended - doc: | - The program with which the simulation was performed. - program(NX_CHAR): - \@version(NX_CHAR): - environment(NXcollection): - exists: recommended - doc: | - Programs and libraries representing the computational environment - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - config(NXparameters): - exists: optional - doc: | - Configuration of the simulation - results(NXprocess): - exists: optional - doc: | - Results of the simulation - (NXimage): - exists: ['min', '0', 'max', 'unbounded'] - (NXspectrum): - exists: ['min', '0', 'max', 'unbounded'] - interaction_volumeID(NXinteraction_volume_em): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - (NXdata): - exists: recommended - (NXprocess): - exists: recommended - - # relevant research result post-processed for specific community methods - # but normalized in its representation ready to be consumed for - # research data management systems - roiID(NXroi): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - doc: | - xref: - spec: EMglossary - term: Region Of Interest - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 - - # as soon as one entry is here constrained further - # an RDM can be sure to find specific pieces of information in a - # specific way but then every user of this application definition - # is required to provide such information in this way! - img(NXem_img): - exists: optional - imageID(NXimage): - nameType: partial - exists: ['min', '1', 'max', 'unbounded'] - imaging_mode(NX_CHAR): - - # (NXmicrostructure): - # exists: optional - ebsd(NXem_ebsd): - exists: optional - gnomonic_reference_frame(NXcoordinate_system): - exists: recommended - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - origin(NX_CHAR): - x(NX_NUMBER): - x_direction(NX_CHAR): - exists: recommended - y(NX_NUMBER): - y_direction(NX_CHAR): - exists: recommended - z(NX_NUMBER): - z_direction(NX_CHAR): - exists: recommended - pattern_center(NXprocess): - exists: recommended - x_boundary_convention(NX_CHAR): - x_normalization_direction(NX_CHAR): - y_boundary_convention(NX_CHAR): - y_normalization_direction(NX_CHAR): - measurement(NXprocess): - exists: optional - depends_on(NX_CHAR): - source(NXnote): - type(NX_CHAR): - exists: recommended - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - simulation(NXprocess): - exists: optional - depends_on(NX_CHAR): - source(NXnote): - type(NX_CHAR): - exists: recommended - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - calibration(NXprocess): - exists: recommended - indexing(NXprocess): - exists: optional - number_of_scan_points(NX_UINT): - indexing_rate(NX_NUMBER): - exists: recommended - source(NXnote): - exists: optional - type(NX_CHAR): - exists: recommended - file_name(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - - # per scan point quantities (identifier_phase, matching_phase, positions, etc.) - # just using the implicit optional, for the database example in NOMAD we do - # not wish to duplicate all payload data - phaseID(NXphase): - nameType: partial - exists: ['min', '0', 'max', 'unbounded'] - name(NX_CHAR): - exists: recommended - number_of_scan_points(NX_UINT): - unit_cell(NXunit_cell): - a(NX_NUMBER): - b(NX_NUMBER): - c(NX_NUMBER): - alpha(NX_NUMBER): - beta(NX_NUMBER): - gamma(NX_NUMBER): - space_group(NX_CHAR): - - # foreseen place for phase-specific texture and microstructure representations and statistics - # ipfID(NXmicrostructure_ipf): - # nameType: partial - # exists: ['min', '1', 'max', 'unbounded'] - # color_model(NX_CHAR): - # projection_direction(NX_NUMBER): - # map(NXdata): - # \@signal(NX_CHAR): - # \@axes(NX_CHAR): - # \@AXISNAME_indices(NX_UINT): - # nameType: partial - # title(NX_CHAR): - # exists: recommended - # data(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_x(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_y(NX_NUMBER): - # exists: optional - # \@long_name(NX_CHAR): - # axis_z(NX_NUMBER): - # exists: optional - # \@long_name(NX_CHAR): - # legend(NXdata): - # \@signal(NX_CHAR): - # \@axes(NX_CHAR): - # \@AXISNAME_indices(NX_UINT): - # nameType: partial - # title(NX_CHAR): - # exists: recommended - # data(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_x(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_y(NX_NUMBER): - # \@long_name(NX_CHAR): - # odfID(NXmicrostructure_odf): - # nameType: partial - # exists: optional - # pfID(NXmicrostructure_pf): - # nameType: partial - # exists: optional - # microstructureID(NXmicrostructure): - # nameType: partial - # exists: optional - roi(NXdata): - exists: recommended - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - descriptor(NX_CHAR): - exists: recommended - data(NX_NUMBER): - axis_z(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - eds(NXem_eds): - exists: optional - - # remains to be discussed based on examples - indexing(NXprocess): - summary(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - axis_energy(NX_CHAR): - \@long_name(NX_CHAR): - atom_types(NX_CHAR): - ELEMENT_SPECIFIC_MAP(NXimage): - exists: ['min', '0', 'max', '118'] - iupac_line_candidates(NX_CHAR): - exists: recommended - energy_range(NX_NUMBER): - image_2d(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - intensity(NX_NUMBER): - \@units(NX_CHAR): - exists: recommended - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - \@units(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - \@units(NX_CHAR): - eels(NXem_eels): - exists: optional - - # see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem - # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2ca934ccb15d8450e2421bb927621119c3925ae5187835f8016366ca45675405 -# -# -# -# -# -# Application definition for normalized representation of electron microscopy research. -# -# This application definition is a comprehensive, general description for the -# standardization of data and metadata collected using electron microscopy. -# -# NXem is designed to be used for documenting experiments or computer simulations in which -# controlled electron beams are used to study electron-beam matter interactions, explore -# physical mechanisms and phenomena, or to characterize materials with an electron microscope. -# -# -# -# -# -# -# -# -# -# The configuration of the software that was used to generate this NeXus file. -# -# -# -# A collection of all programs and libraries used to generate this NeXus file. -# Ideally, this would enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific set -# of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# Instances can also be used to document the modules and libraries that -# are offered by the computational environment such as those parsed -# from conda or python virtualenv environments. -# -# -# -# -# -# -# -# -# A (globally) unique persistent identifier for referring to this experiment. -# -# -# -# -# Alias (short name) which scientists can use to refer to this experiment. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into the 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 - use this start_time field. -# -# Often though it is useful to specify a time interval via setting both a start_time -# and an end_time because this enables software tools and users to collect a -# more detailed bookkeeping of the experiment. -# -# Users should be aware though that even using only start_time and end_time -# may not be sufficient to infer how long the experiment took or for how long -# data were acquired. To bookkeep more fine-grained timestamps over the -# course of the experiment is possible with start_time and end_time fields -# of respective :ref:`NXevent_data_em` instances. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included when -# the microscope session ended. -# -# See docstring of the start_time field to see how to use the -# start_time and end_time together. -# -# -# -# -# -# Collection of serialized resources associated with the experiment. -# Examples of such resources are files which are formatted using proprietary -# data models of technology partners as those generated by the control software -# of the microscope during the instrument session. -# -# -# -# -# -# -# -# -# Information about persons who performed or were involved in the microscope -# session or simulation run. -# -# -# -# -# -# -# Given (first) name and surname. -# -# -# -# -# Name of the affiliation at the point in time when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address at the point in time when the experiment was performed. -# -# Writing the most permanently used email is recommended. -# -# -# -# -# Telephone number at the point in time when the experiment was performed. -# -# -# -# -# User role at the point in time when the experiment was performed. -# -# Examples are technician operating the microscope, student, postdoc, -# principle investigator, or guest. -# -# -# -# -# -# A physical entity which contains material intended to be investigated. -# Sample and specimen are treated as de facto synonyms. -# Samples can be real or virtual ones as annotated via is_simulation. -# -# The suggested best practice is to call this group sample. In those cases when -# multiple samples need to be grouped inside one entry, these SAMPLE groups -# should be named using the prefix sample followed an index starting from 1, i.e. -# (sample1, sample2). -# -# There are at least two strategies how to store (meta)data when one analyzes multiple -# samples - not different ROIs on a single sample though - in one session. -# -# One strategy is to store each sample and its results under an own NXem/ENTRY. -# This is one of the most frequent use cases as during most sessions typically only a -# single sample is investigated. In this case the name of this group should be NXem/ENTRY/sample. -# -# If multiple samples are investigated storing each of them in their own ENTRY group eventually will -# demand unnecessary duplication of instrument details. -# -# This can be avoided by using another strategy for storing samples and their results. -# Namely, by using only one instance of NXem/ENTRY. That NXem/ENTRY should then be named, -# like in the previous case, NXem/entry1 and the samples should be named sample1, sample2, etc., -# i.e. instances should use sample as a name prefix. -# -# In this case the collection of events should use identifier_sample to state clearly for which -# of the samples loaded the (characterization) event was detected. -# -# This concept is related to term `Specimen`_ of the EMglossary standard. -# -# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 -# -# -# -# Qualifier whether the sample is a real (in which case is_simulation should be set to false) -# or a virtual one (in which case is_simulation should be set to true). -# -# -# -# -# -# -# -# -# -# -# -# -# Ideally, (globally) unique persistent identifier which distinguishes this sample from all others -# and especially the predecessor/origin from where that sample was cut off. An example of cutting off -# is a steel sheet that is the parent sample from which a small portion was wire-eroded that -# represents the sample that was then prepared for characterization with an electron microscope. -# -# The terms sample and specimen are here considered as exact synonyms. -# -# This field must not be used for an alias for the sample name. Instead, use name. -# -# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve -# the specific sample, whose results are stored by this :ref:`NXentry` instance, because a single -# NXentry should be used for the characterization of a single specimen. -# -# Details about the specimen preparation should be stored in resources referring to identifier_parent. -# -# -# -# -# -# Identifier of the sample from which the sample was cut off or the string *None*. -# I.e. the parent to this sample. -# -# The purpose of this field is to support functionalities for tracking -# sample provenance in a research data management system. -# -# -# -# -# -# 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 timestamp when -# the measured specimen surface was actively prepared. Ideally, this matches -# the last timestamp that is mentioned in the digital resource pointed to by -# identifier_parent. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is especially -# required for material that is sensitive to the environment such as specimens that were -# charged with fast diffusing elements or short-lived radioactive tracers. -# -# Additional time stamps prior to preparation_date are better placed in resources which -# describe but do not pollute the description here with prose. Resolving these -# connected metadata is considered the responsibility of the research data management -# system and not the a NeXus file. -# -# -# -# -# Specimen name -# -# -# -# -# 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 research data management systems an opportunity -# to parse the relevant elements without having to interpret these from the resources -# pointed to by identifier_parent or walk through eventually deeply nested groups in -# individual data instances. -# -# -# -# -# (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 typically 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 a -# region-of-interest connected to individual :ref:`NXevent_data_em` -# instances can provide a cleaner description of the relevant details. -# -# -# -# -# Discouraged free-text field to provide further detail. -# -# -# -# -# -# The conventions used when reporting crystal orientations. -# We follow the best practices of the Material Science community -# that are defined in reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin. -# This is in accordance with convention 2 of reference `<https://doi.org/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 reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# The most frequently used convention in Materials Science is zxz, which is based on the work -# of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished -# from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parametrizations/representations according -# to convention 6 of reference `<https://doi.org/10.1088/0965-0393/23/8/083501>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Location of the origin of the processing_reference_frame. -# -# It is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the specifically named :ref:`NXsample` instance(s) for -# which these conventions apply (e.g. /entry1/sample1). -# -# -# -# -# -# -# Location of the origin of the sample_reference_frame. -# -# It is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The reference frame that is defined by a specific detector. -# -# -# -# Reference to the specifically named :ref:`NXdetector` instance for -# which these conventions apply (e.g. /entry1/instrument/detector1). -# -# -# -# -# -# -# Location of the origin of the detector_reference_frame. -# -# If the regions-of-interest forms a rectangle or cuboid, it is assumed that 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. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the control program used for operating the microscope. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A spherical aberration corrector is a typical component in a transmission electron microscope. -# Many instruments have only one, in this case the variadic suffix should be dropped. -# If there are multiple instances these should be numbered starting from 1, i.e. corrector_cs1, -# corrector_cs2. -# -# -# -# Use specifically when there are multiple instances. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptor for the aperture setting 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 users. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptor for the aperture setting 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 users. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Operation mode of the detector as displayed by the control software. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Nominal current of the heater. -# -# -# -# -# Nominal voltage of the heater. -# -# -# -# -# -# -# -# -# -# -# -# -# Documentation for a simulation of electron beam-matter interaction. -# -# -# -# The program with which the simulation was performed. -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# Configuration of the simulation -# -# -# -# -# Results of the simulation -# -# -# -# -# -# -# -# -# -# -# -# -# This concept is related to term `Region Of Interest`_ of the EMglossary standard. -# -# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml deleted file mode 100644 index 4074e3c9ed..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ /dev/null @@ -1,1178 +0,0 @@ -category: base -doc: -- | - Base class method-specific for Electron Backscatter Diffraction (EBSD). -- | - The general procedure of an EBSD experiment is as follows: - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance - and tilt the stage into diffraction conditions. -- | - Users then typically configure the microscope for collecting quality data. - The EBSD detector is pushed in (if retractable). Subsequently, they fine tune - the illumination and aberration corrector settings and select one or multiple ROIs - for the microscope to machine off automatically. They configure on-the-fly - indexing parameter and then typically start the measurement queue. - From this point onwards typically the microscope runs automatically. -- | - Diffraction pattern get collected until the queue finishes or gets interrupted by - either errors or arrival at the end of the users' allocated timeslot at the instrument. -- | - Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. - Once indexed, these patterns are often not stored. -- | - Results are stored in files, which afterwards are typically copied - automatically or manually for archival purposes to certain storage - locations for further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. -- | - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy exemplified here for electron backscatter diffraction (EBSD). - The base class solves two key documentation issues within the EBSD community: -- | - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted - according to NXem_ebsd) stores the connection between the microscope session and - the key datasets which are considered typically results of the afore-mentioned - steps involved in an EBSD experiment. -- | - Different groups in NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed, and many more (meta)data. -- | - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every experiment or simulation using EBSD. -- | - Otherwise, results would be ripped out of their context like it is the current situation - with many traditional studies where EBSD data were indexed on-the-fly and shared - with the community only via sharing the strongly processed files with results in some - formatting but without communicating all conventions used or just relying on the assumptions - that colleagues likely know these conventions even though - multiple definitions are possible. -- | - NXem_ebsd 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) experiments - where a combination of repetitive removal of material from the surface layer to measure - otherwise the same region-of-interest at different depth increments. Material removal - can be achieved with mechanical, electron, or ion polishing, using manual steps or - automated equipment like a robot system `S. Tsai et al. `_. -- | - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By virtue of design, these methods are destructive - either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. -- | - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these images are indexed to process - a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint - also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. -- | - xref: - spec: EMglossary - term: Electron Backscatter Diffraction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 -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 plot orientation mapping. - n_y: | - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - n_x: | - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - n_solutions: | - Number of phase solutions - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). -type: group -NXem_ebsd(NXprocess): - gnomonic_reference_frame(NXcoordinate_system): - doc: | - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions are not met, the user is required to explicitly state this. - - Reference ``_ suggests to label the - base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. - origin(NX_CHAR): - doc: | - Origin of the gnomonic_reference_frame. - - Reference ``_ suggests to - assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. - enumeration: [in_the_pattern_center] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. - enumeration: [north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. - enumeration: [north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. - enumeration: [north, east, south, west, in, out] - pattern_center(NXprocess): - doc: | - Details about the definition of the pattern center as a special point in the - gnomonic_reference_frame. - - Typically the gnomonic space is embedded in the detector space. - Specifically, the XgYg plane is defined such that it is 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 - one effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height, though, is that these become degenerated - if the detector region-of-interest is square-shaped. This is why instead of referring to - width and height it is better to state explicitly which direction is considered positive - when measuring distances. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. - x_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference frame) is the pattern - center's x-position (PCx) measured. - enumeration: [top, right, bottom, left] - x_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. - enumeration: [north, east, south, west] - y_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference frame) is the pattern - center's y-position (PCy) measured. - enumeration: [top, right, bottom, left] - y_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. - enumeration: [north, east, south, west] - measurement(NXprocess): - doc: | - This group documents relevant details about the conditions and the - tools for measuring diffraction patterns with an electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interest using a discretization into square or hexagon tiles. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Physical time since the beginning of a timestamp that is required to be - the same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set need 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, - 30 minutes, 6 hours, or 24 hours of annealing. - \@epoch_start(NX_CHAR): - doc: | - Timestamp relative to which time was counted to aid - converting between time and timestamp. - depends_on(NX_CHAR): - doc: | - Path to an instance of :ref:`NXdata` where the measured patterns are stored. - source(NXnote): - doc: | - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured patterns or input (already processed EBSD data). - simulation(NXprocess): - doc: | - This group documents relevant details about the conditions and the tools - used for simulating diffraction patterns with some physical model. - - This group should be used if (e.g. instead of a measurement) the patterns - were simulated (possibly awaiting indexing). - - In many practical cases where patterns are analyzed on-the-fly and dictionary - indexing strategies used, so-called master pattern(s) are used to compare - measured or simulated patterns with the master patterns. - depends_on(NX_CHAR): - doc: | - Path to an instance of :ref:`NXimage` where the simulated patterns are stored. - source(NXnote): - doc: | - Reference (e.g. path and filename) to an existent digital resource which - stores either the patterns or input (already processed EBSD data) that are - about to become processed further as described by this NXem_ebsd instance. - calibration(NXprocess): - doc: | - The EBSD system, including components like the electron gun, pole-piece, - stage tilt, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable, precise, and accurate scientific results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, standard specimens made from silicon or quartz crystals - in specific orientations are used for this purpose. - - Considering that a system used is already calibrated well-enough is much - more frequently the case in practice than that users perform the calibration - themselves (with above-mentioned standard specimens). - - 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 has been calibrated already. Consequently, users pick from - an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. - Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and how this setup in the GUI. - - 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' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` - solves in that all conventions can be specified explicitly. - depends_on(NX_CHAR): - doc: | - Path to an instance of :ref:`NXem` where calibration data are stored. - source(NXnote): - doc: | - Reference to a digital resource where the calibration is stored. - indexing(NXprocess): - doc: | - Indexing is a data processing step performed either after or while (aka on-the-fly) - the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSP. Common to them is the - computational step where simulated or theoretically assumed patterns - are compared with the measured ones. These latter patterns are referred - to via the measurement or simulation groups of this base class respectively. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - patterns are, and thus if no, one, or multiple so-called solutions were found. - - Assumed or simulated patterns are simulated using kinematical or dynamical - theory of electron diffraction delivering master patterns. - - The Hough transform, one of the most frequently used traditional method for indexing - EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. `_). Recently, dictionary-based and artificial intelligence-based methods - find more widespread usage for indexing. - source(NXnote): - doc: | - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - method(NX_CHAR): - doc: | - Principal algorithm used for indexing. - enumeration: - open_enum: true - items: [hough_transform, dictionary, radon_transform] - background_correction(NXprocess): - doc: | - Details about the background correction applied to each Kikuchi pattern. - binning(NXprocess): - doc: | - Binning i.e. downsampling to each pattern. - parameter(NXcollection): - doc: | - Specific parameter relevant only for certain algorithms used. - phaseID(NXphase): - nameType: partial - doc: | - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXunit_cell` in this group must - have the group name prefixed with phase. The identifier in the name is an - integer. Start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, the null phase also known - as notIndexed. - dspacing(NX_NUMBER): - unit: NX_LENGTH - doc: | - Spacing between the crystallographic planes that are defined via ``miller``. - dimensions: - rank: 1 - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Relative intensity for the computed diffraction intensity (signal) for the - plane. - dimensions: - rank: 1 - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - unit: NX_UNITLESS - doc: | - In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps - this field stores how many scan points of the map were identified as matching best - with this phase. - number_of_planes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many reflectors for crystallographic planes are distinguished. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - dimensions: - rank: 2 - dim: (n_hkl, 6) - status(NX_UINT): - unit: NX_UNITLESS - doc: | - Which return value did the indexing algorithm yield for each scan point. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - dimensions: - rank: 1 - dim: (n_sc,) - phases_per_scan_point(NX_INT): - unit: NX_UNITLESS - 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 :ref:`NXunit_cell`. - - In another example users may have skipped some scan points (not indexed - them at all) or used differing numbers of phases for indexing different scan points. - - The cumulated of this array decodes how identifier_phase and matching_phase - 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), - identifier_phase has as many entries as scan points - and matching_phase has also as many entries as scan points. - dimensions: - rank: 1 - dim: (n_sc,) - identifier_phase(NX_INT): - unit: NX_UNITLESS - doc: | - The array phases_per_scan_point details how the identifier_phase - and the matching_phase arrays have to be interpreted. - - For the example with a single phase identifier_phase 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 - required) that a pattern matches eventually (not equally well) sufficiently - significant with multiple patterns. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models. Having such field is especially relevant - for recent dictionary- or artificial intelligence-based indexing methods to communicate - the results in a model-agnostic way in combination with matching_phase. - - Depending on the phases_per_scan_point value, identifier_phase and - matching_phase arrays represent a collection of concatenated tuples. - These 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 phases_per_scan_point. - dimensions: - rank: 1 - dim: (n_solutions,) - matching_phase(NX_INT): - unit: NX_UNITLESS - doc: | - One-dimensional array, pattern by pattern labelling the solutions found. - The array phases_per_scan_point has to be specified because it details - how the identifier_phase and the matching_phase arrays are interpreted. - See documentation of identifier_phase for further details. - dimensions: - rank: 1 - dim: (n_solutions,) - matching_phase_descriptor(NX_CHAR): - doc: | - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence_index, mean_angular_deviation, or other. - enumeration: [confidence_index, mean_angular_deviation, other] - rotation(NXrotations): - scan_point_positions(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center positions of each scan point - in the sample surface reference system. - dimensions: - rank: 2 - dim: (n_sc, 2) - indexing_rate(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Fraction of successfully indexed patterns with a phase - not the null-phase vs the number_of_scan_points. - number_of_scan_points(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of scan points in the original mapping. - - # - # - # - # - roi(NXdata): - doc: | - An overview of the entire ROI. - descriptor(NX_CHAR): - doc: | - Descriptor representing the image contrast. - enumeration: [band_contrast, confidence_index, mean_angular_deviation] - title(NX_CHAR): - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dimensions: - rank: 2 - dim: (n_y, n_x) - \@long_name(NX_CHAR): - doc: | - Descriptor values - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dimensions: - rank: 1 - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dimensions: - rank: 1 - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Label for the x axis - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 82a3639815330347d1689d9057a7881b35944b189b49d76b005137bc07062ade -# -# -# -# -# -# -# -# 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 plot orientation mapping. -# -# -# -# -# Number of pixel along slow changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of pixel along fast changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of phase solutions -# -# -# -# -# Number of reflectors (Miller crystallographic plane triplets). -# -# -# -# -# Base class method-specific for Electron Backscatter Diffraction (EBSD). -# -# The general procedure of an EBSD experiment is as follows: -# Users load the specimen, collect first a coarse image of the surface. -# Next, they set an approximate value for the calibrated working distance -# and tilt the stage into diffraction conditions. -# -# Users then typically configure the microscope for collecting quality data. -# The EBSD detector is pushed in (if retractable). Subsequently, they fine tune -# the illumination and aberration corrector settings and select one or multiple ROIs -# for the microscope to machine off automatically. They configure on-the-fly -# indexing parameter and then typically start the measurement queue. -# From this point onwards typically the microscope runs automatically. -# -# Diffraction pattern get collected until the queue finishes or gets interrupted by -# either errors or arrival at the end of the users' allocated timeslot at the instrument. -# -# Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. -# Once indexed, these patterns are often not stored. -# -# Results are stored in files, which afterwards are typically copied -# automatically or manually for archival purposes to certain storage -# locations for further consumption. The result of such an EBSD -# measurement/experiment is a set of usually proprietary or open files -# from technology partners. -# -# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific -# data, metadata, and connections between these for the research field of -# electron microscopy exemplified here for electron backscatter diffraction (EBSD). -# The base class solves two key documentation issues within the EBSD community: -# -# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted -# according to NXem_ebsd) stores the connection between the microscope session and -# the key datasets which are considered typically results of the afore-mentioned -# steps involved in an EBSD experiment. -# -# Different groups in NXem_ebsd make connections to data artifacts which were collected -# when working with electron microscopes via the NXem 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 acquisition and eventual indexing of Kikuchi patterns, -# associated overview images, like secondary electron or backscattered electron -# images of the region-of-interest probed, and many more (meta)data. -# -# Secondly, NXem_ebsd connects and stores the conventions and reference frames -# which were used and which are the key to a correct mathematical interpretation -# of every experiment or simulation using EBSD. -# -# Otherwise, results would be ripped out of their context like it is the current situation -# with many traditional studies where EBSD data were indexed on-the-fly and shared -# with the community only via sharing the strongly processed files with results in some -# formatting but without communicating all conventions used or just relying on the assumptions -# that colleagues likely know these conventions even though -# multiple definitions are possible. -# -# NXem_ebsd 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) experiments -# where a combination of repetitive removal of material from the surface layer to measure -# otherwise the same region-of-interest at different depth increments. Material removal -# can be achieved with mechanical, electron, or ion polishing, using manual steps or -# automated equipment like a robot system `S. Tsai et al. <https://doi.org/10.1063/5.0087945>`_. -# -# Three-dimensional experiments require to follow a sequence of specimen, surface -# preparation, and data collection steps. By virtue of design, these methods are destructive -# either because of the necessary material removal or surface degradation 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 via 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 contextualized and connected. -# -# Eventual tomography methods also use such a workflow because first diffraction -# images are collected (e.g. with X-ray) and then these images are indexed to process -# a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint -# also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM. -# -# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. -# -# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 -# -# -# -# Details about the gnomonic (projection) reference frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions are not met, the user is required to explicitly state this. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to label the -# base vectors of this coordinate system as :math:`X_g, Y_g, Z_g`. -# -# -# -# Origin of the gnomonic_reference_frame. -# -# Reference `<https://doi.org/10.1016/j.matchar.2016.04.008>`_ suggests to -# assume that this is coordinate :math:`Xg = 0, Yg = 0, Zg = 0`. -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the definition of the pattern center as a special point in the -# gnomonic_reference_frame. -# -# Typically the gnomonic space is embedded in the detector space. -# Specifically, the XgYg plane is defined such that it is 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 -# one effectively normalizes in fractions of the width of the detector. -# -# The issue with terms like width and height, though, is that these become degenerated -# if the detector region-of-interest is square-shaped. This is why instead of referring to -# width and height it is better to state explicitly which direction is considered positive -# when measuring distances. -# -# For the concepts used to specify the boundary_convention it is assumed that the -# region-of-interest is defined by a rectangle, referring to the direction of outer-unit -# normals to the respective edges of this rectangle. -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# center's x-position (PCx) measured. -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the x-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# center's y-position (PCy) measured. -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the y-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# -# This group documents relevant details about the conditions and the -# tools for measuring diffraction patterns with an electron microscope. -# -# The most frequently collected EBSD data are captured for rectangular -# regions-of-interest using a discretization into square or hexagon tiles. -# -# -# -# Physical time since the beginning of a timestamp that is required to be -# the same for all experiments in the set. The purpose of this marker is -# to identify how all experiments in the set need 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, -# 30 minutes, 6 hours, or 24 hours of annealing. -# -# -# -# Timestamp relative to which time was counted to aid -# converting between time and timestamp. -# -# -# -# -# -# Path to an instance of :ref:`NXdata` where the measured patterns are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent data artifact which -# stores either the measured patterns or input (already processed EBSD data). -# -# -# -# -# -# This group documents relevant details about the conditions and the tools -# used for simulating diffraction patterns with some physical model. -# -# This group should be used if (e.g. instead of a measurement) the patterns -# were simulated (possibly awaiting indexing). -# -# In many practical cases where patterns are analyzed on-the-fly and dictionary -# indexing strategies used, so-called master pattern(s) are used to compare -# measured or simulated patterns with the master patterns. -# -# -# -# Path to an instance of :ref:`NXimage` where the simulated patterns are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent digital resource which -# stores either the patterns or input (already processed EBSD data) that are -# about to become processed further as described by this NXem_ebsd instance. -# -# -# -# -# -# The EBSD system, including components like the electron gun, pole-piece, -# stage tilt, EBSD detector, and the gnomonic projection have to be -# calibrated to achieve reliable, precise, and accurate scientific results. -# -# Specifically, the gnomonic projection has to be calibrated. -# Typically, standard specimens made from silicon or quartz crystals -# in specific orientations are used for this purpose. -# -# Considering that a system used is already calibrated well-enough is much -# more frequently the case in practice than that users perform the calibration -# themselves (with above-mentioned standard specimens). -# -# 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 has been calibrated already. Consequently, users pick from -# an existent library of phase candidates, i.e. :ref:`NXunit_cell` instances. -# Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco). -# -# In the second case, users calibrate the system during the session -# using standards (silicon, quartz, or other common specimens). -# There is usually one person in each lab responsible for doing such -# calibrations. Often this person or technician is 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: Taking TSL OIM/EDAX as an example, -# the conventions how orientations are stored is affected by how the -# reference frames are configured and how this setup in the GUI. -# -# 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' obligation to remember these -# settings or write these down in a lab notebook. Otherwise, these metadata -# get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` -# solves in that all conventions can be specified explicitly. -# -# -# -# Path to an instance of :ref:`NXem` where calibration data are stored. -# -# -# -# -# Reference to a digital resource where the calibration is stored. -# -# -# -# -# -# Indexing is a data processing step performed either after or while (aka on-the-fly) -# the beam scans the specimen. The resulting method is also -# known as orientation imaging microscopy (OIM). -# -# Different algorithms can be used to index EBSP. Common to them is the -# computational step where simulated or theoretically assumed patterns -# are compared with the measured ones. These latter patterns are referred -# to via the measurement or simulation groups of this base class respectively. -# -# Quality descriptors are defined based on which an indexing algorithm -# yields a quantitative measure of how similar measured and reference -# patterns are, and thus if no, one, or multiple so-called solutions were found. -# -# Assumed or simulated patterns are simulated using kinematical or dynamical -# theory of electron diffraction delivering master patterns. -# -# The Hough transform, one of the most frequently used traditional method for indexing -# EBSP is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). Recently, dictionary-based and artificial intelligence-based methods -# find more widespread usage for indexing. -# -# -# -# This group enables to establish a logical connection between previous -# processing steps or on-the-fly-performed indexing of the EBSD map. -# Typically these processing steps are performed with commercial software. -# Therefore, in many cases a results file from this indexing is often -# all that is communicated and saved. These are typically files in a format -# specific to the instrument and its configuration. -# -# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. -# -# -# -# -# Principal algorithm used for indexing. -# -# -# -# -# -# -# -# -# -# Details about the background correction applied to each Kikuchi pattern. -# -# -# -# -# Binning i.e. downsampling to each pattern. -# -# -# -# -# Specific parameter relevant only for certain algorithms used. -# -# -# -# -# Details for each phase used as a model with which the patterns were -# indexed. Instances of :ref:`NXunit_cell` in this group must -# have the group name prefixed with phase. The identifier in the name is an -# integer. Start counting from 1 because the value 0 is reserved for -# the special phase that is the null-model, the null phase also known -# as notIndexed. -# -# -# -# Spacing between the crystallographic planes that are defined via ``miller``. -# -# -# -# -# -# -# -# Relative intensity for the computed diffraction intensity (signal) for the -# plane. -# -# -# -# -# -# -# -# In case the :ref:`NXunit_cell` base class is used with analyzed orientation maps -# this field stores how many scan points of the map were identified as matching best -# with this phase. -# -# -# -# -# How many reflectors for crystallographic planes are distinguished. -# -# -# -# -# Miller indices :math:`(hkl)[uvw]` of the planes. -# -# The first triplet specifies :math:`(hkl)`. The second triplet specifies :math:`[uvw]`. -# Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. -# -# -# -# -# -# -# -# -# -# Which return value did the indexing algorithm yield for each scan point. -# -# * 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 :ref:`NXunit_cell`. -# -# In another example users may have skipped some scan points (not indexed -# them at all) or used differing numbers of phases for indexing different scan points. -# -# The cumulated of this array decodes how identifier_phase and matching_phase -# 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), -# identifier_phase has as many entries as scan points -# and matching_phase has also as many entries as scan points. -# -# -# -# -# -# -# -# The array phases_per_scan_point details how the identifier_phase -# and the matching_phase arrays have to be interpreted. -# -# For the example with a single phase identifier_phase 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 -# required) that a pattern matches eventually (not equally well) sufficiently -# significant with multiple patterns. This can especially happen in cases of -# pseudosymmetry and more frequently with an improperly calibrated system -# or false or inaccurate phase models. Having such field is especially relevant -# for recent dictionary- or artificial intelligence-based indexing methods to communicate -# the results in a model-agnostic way in combination with matching_phase. -# -# Depending on the phases_per_scan_point value, identifier_phase and -# matching_phase arrays represent a collection of concatenated tuples. -# These 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 phases_per_scan_point. -# -# -# -# -# -# -# -# One-dimensional array, pattern by pattern labelling the solutions found. -# The array phases_per_scan_point has to be specified because it details -# how the identifier_phase and the matching_phase arrays are interpreted. -# See documentation of identifier_phase for further details. -# -# -# -# -# -# -# -# Phase_matching is a descriptor for how well the solution matches or not. -# Examples can be confidence_index, mean_angular_deviation, or other. -# -# -# -# -# -# -# -# -# -# -# Calibrated center positions of each scan point -# in the sample surface reference system. -# -# -# -# -# -# -# -# -# Fraction of successfully indexed patterns with a phase -# not the null-phase vs the number_of_scan_points. -# -# -# -# -# Number of scan points in the original mapping. -# -# -# -# -# -# An overview of the entire ROI. -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# -# -# -# -# Title of the default plot. -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# Descriptor values -# -# -# -# -# -# Calibrated coordinate along the y-axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated coordinate along the x-axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 45c47c50d2..0000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,336 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). - - `IUPAC instead of Siegbahn notation `_ should be used. - - X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental - characterization requires typically a sequence of characterization and preparation of the - surface to expose new surface layer that can be characterized in the next acquisition. - In effect, the resulting three-dimensional elemental information mappings are truly the - result of a correlation and post-processing of several measurements which is the field - of correlative tomographic usage of electron microscopy. -symbols: - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected - n_iupac_line_names: | - Number of IUPAC line names -type: group -NXem_eds(NXprocess): - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - summary(NXdata): - doc: | - Accumulated intensity over all pixels of the region-of-interest. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Accumulated counts - dimensions: - rank: 1 - dim: (n_photon_energy,) - \@long_name(NX_CHAR): - doc: | - Counts - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_photon_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - atom_types(NX_CHAR): - doc: | - Comma-separated list of symbols for elements from the periodic table that have - been confirmed present by the here reported EDS analysis. - - This field can be used when creating instances of :ref:`NXpeak` is not desired. - However, a collection of instances of NXpeak with individual NXatom - can be used to add isotopic information and other relevant context. - (NXpeak): - doc: | - Details about individual indexed peaks. - (NXatom): - energy_range(NX_NUMBER): - unit: NX_ENERGY - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - dimensions: - rank: 1 - dim: (2,) - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Theoretical energy of the line according to IUPAC. - iupac_line_name(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 grouped with the same peak. - dimensions: - rank: 1 - dim: (n_iupac_line_names,) - ELEMENT_SPECIFIC_MAP(NXimage): - nameType: any - doc: | - Individual element-specific EDS/EDX/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. - - These element-specific EDS maps are instances of :ref:`NXimage` - that should be named by the element from the atom_types field. - - When signal contributions from several peaks were decomposed - users should ideally use a respective number of NXpeak instances - to give further context about the individual signal contributions - are summarized and shown together, e.g. the combined signal - under the curve of carbon and oxygen. - - In this case specify the processing details use peak and weight. - description(NX_CHAR): - doc: | - Discouraged free-text field to add additional information. - iupac_line_candidates(NX_CHAR): - doc: | - Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that - documents which elements and their specific lines are theoretically located within - the energy_range of the spectrum from which the EDS (element) map was computed. - energy_range(NX_NUMBER): - unit: NX_ENERGY - doc: | - Associated :math:`[e_{min}, e_{max}]` bounds of the energy - range for which spectrum counts were accumulated. - dimensions: - rank: 1 - dim: (2,) - (NXprocess): - peak(NX_CHAR): - doc: | - A list of :ref:`NXpeak` instance names whose X-ray quanta were - accumulated for each pixel to obtain an element-specific - EDS map. - dimensions: - rank: 1 - dim: (n_peaks,) - weight(NX_NUMBER): - unit: NX_UNITLESS - doc: | - A list of weights by how much the intensity of each peak - contributes to the intensity of the EDS map. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3903897979b6ea01fe3d2ffbcfc0642fe9593e9419111b1d5de3f419609f3505 -# -# -# -# -# -# -# -# Number of X-ray photon energy (bins) -# -# -# -# -# Number of identified elements -# -# -# -# -# Number of peaks detected -# -# -# -# -# Number of IUPAC line names -# -# -# -# -# Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). -# -# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. -# -# X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental -# characterization requires typically a sequence of characterization and preparation of the -# surface to expose new surface layer that can be characterized in the next acquisition. -# In effect, the resulting three-dimensional elemental information mappings are truly the -# result of a correlation and post-processing of several measurements which is the field -# of correlative tomographic usage of electron microscopy. -# -# -# -# Details about computational steps how peaks were indexed as elements. -# -# -# -# The program with which the indexing was performed. -# -# -# -# -# Accumulated intensity over all pixels of the region-of-interest. -# -# -# -# Accumulated counts -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Comma-separated list of symbols for elements from the periodic table that have -# been confirmed present by the here reported EDS analysis. -# -# This field can be used when creating instances of :ref:`NXpeak` is not desired. -# However, a collection of instances of NXpeak with individual NXatom -# can be used to add isotopic information and other relevant context. -# -# -# -# -# Details about individual indexed peaks. -# -# -# -# -# Associated lower :math:`[e_{min}, e_{max}]` bounds of the -# energy which is assumed associated with this peak. -# -# -# -# -# -# -# -# Theoretical energy of the line according to IUPAC. -# -# -# -# -# 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 grouped with the same peak. -# -# -# -# -# -# -# -# -# -# Individual element-specific EDS/EDX/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. -# -# These element-specific EDS maps are instances of :ref:`NXimage` -# that should be named by the element from the atom_types field. -# -# When signal contributions from several peaks were decomposed -# users should ideally use a respective number of NXpeak instances -# to give further context about the individual signal contributions -# are summarized and shown together, e.g. the combined signal -# under the curve of carbon and oxygen. -# -# In this case specify the processing details use peak and weight. -# -# -# -# Discouraged free-text field to add additional information. -# -# -# -# -# Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that -# documents which elements and their specific lines are theoretically located within -# the energy_range of the spectrum from which the EDS (element) map was computed. -# -# -# -# -# Associated :math:`[e_{min}, e_{max}]` bounds of the energy -# range for which spectrum counts were accumulated. -# -# -# -# -# -# -# -# -# A list of :ref:`NXpeak` instance names whose X-ray quanta were -# accumulated for each pixel to obtain an element-specific -# EDS map. -# -# -# -# -# -# -# -# A list of weights by how much the intensity of each peak -# contributes to the intensity of the EDS map. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 85c1f2aa24..0000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -type: group -NXem_eels(NXprocess): - zlp_correction(NXprocess): - doc: | - Details about computational steps how the zero-loss peak was threaded. - (NXprogram): - doc: | - The program with which the zero-loss peak correction was performed. - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - (NXpeak): - doc: | - Name and location of each peak in the spectrum considered to be of relevance. - (NXspectrum): - doc: | - NXspectrum specialized for EELS. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e7654e681ca515cfec03ae8d5052c572a7f40c2770c5e0537e34df4897b2cfbd -# -# -# -# -# -# Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -# -# -# -# Details about computational steps how the zero-loss peak was threaded. -# -# -# -# The program with which the zero-loss peak correction was performed. -# -# -# -# -# -# Details about computational steps how peaks were indexed as elements. -# -# -# -# The program with which the indexing was performed. -# -# -# -# -# Name and location of each peak in the spectrum considered to be of relevance. -# -# -# -# -# NXspectrum specialized for EELS. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 06668b77e4..0000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,98 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging with electron microscopes. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe regions-of-interest (ROIs). Examples can be single point aka spot - measurements, 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. -type: group -NXem_img(NXprocess): - (NXimage): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: - open_enum: true - items: [secondary_electron, backscattered_electron, annular_dark_field, cathodoluminescence] - half_angle_interval(NX_NUMBER): - unit: NX_ANGLE - doc: | - Annulus inner (first value) and outer (second value) half angle. - dimensions: - rank: 1 - dim: (2,) - - # already implemented connections to representations of microstructures but in this PR not proposed - # (NXmicrostructure): - # doc: | - # A reconstruction of the microstructure or some of its features - # based on image information in the parent class. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 399e311c8610e60a5a7e0d69f1271d29d19e6f12bb1cfe372c34eb72118daf3a -# -# -# -# -# -# Base class for method-specific generic imaging with electron microscopes. -# -# In the majority of cases simple d-dimensional regular scan patterns are used -# to probe regions-of-interest (ROIs). Examples can be single point aka spot -# measurements, 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. -# -# -# -# -# Which imaging mode was used? -# -# -# -# -# -# -# -# -# -# -# Annulus inner (first value) and outer (second value) half angle. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_measurement.yaml b/contributed_definitions/nyaml/NXem_measurement.yaml deleted file mode 100644 index 48e4dc84a0..0000000000 --- a/contributed_definitions/nyaml/NXem_measurement.yaml +++ /dev/null @@ -1,41 +0,0 @@ -category: base -doc: | - Base class for documenting a measurement with an electron microscope. -type: group -NXem_measurement(NXobject): - instrument(NXinstrument_em): - eventID(NXevent_data_em): - nameType: partial - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b316172f1da3439b7e2e8914311c4473c77b211748924007325b78d22ab4bfa2 -# -# -# -# -# -# Base class for documenting a measurement with an electron microscope. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_simulation.yaml b/contributed_definitions/nyaml/NXem_simulation.yaml deleted file mode 100644 index 68eba8b949..0000000000 --- a/contributed_definitions/nyaml/NXem_simulation.yaml +++ /dev/null @@ -1,44 +0,0 @@ -category: base -doc: | - Base class for documenting a simulation of electron beam-matter interaction. -type: group -NXem_simulation(NXobject): - (NXprogram): - (NXparameters): - (NXprocess): - (NXdata): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c481ee0c18dbbeebd612e013186b8f69866a0cdbc59610bd02a1d819a1af7af0 -# -# -# -# -# -# Base class for documenting a simulation of electron beam-matter interaction. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml deleted file mode 100644 index ebe89c03e9..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_apm.yaml +++ /dev/null @@ -1,308 +0,0 @@ -category: base -doc: | - Base class to store state and (meta)data of events over the course of an atom probe experiment. - - Having at least one instance for an instance of NXapm is recommended. - - This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs - of atom probe research. Against static and dynamic quantities are split to avoid a duplication - of information. Specifically, the time interval considered is the entire time - starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the pulse_id field. The point in time when each was issued - is specified via the combination of start_time and delta_time. - - Which temporal granularity is adequate depends on the situation and research question. - Using a model which enables a collection of events offers the most flexible way to cater for - both atom probe experiments or simulation. To monitor the course of an ion extraction experiment - (or simulation) it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event - identifier. - - As set and measured quantities typically change over time and we do not yet know during the - measurement which of the events have associated (molecular) ions that will end up in the - reconstructed volume, we must not document quantities as a function of the evaporation_id but - as a function of the (pulsing) identifier_event. - - Conceptually and technically NeXus currently stores tensorial information as arrays of values - (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores - a set of temperature values but that field when used somewhere is a concept. However, that - concept has no information at which point in time these temperatures were taken. - An existent functional relationship between the two concepts is not defined. - - However, a correct interpretation of the temperature values demands knowledge about what is - the independent quantity on which temperature depends on or according to which frequency - temperature values were sampled. - In NeXus there are two approaches which cope with such correlations: - One is :ref:`NXdata` where the attribute signal specifies the correlation. - The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against - (dependent signal) and independent quantities into an own group. - In many cases this additional grouping is not desired though. - - One naive solution typically employed is then to store the independent variable values via a second - vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). - However, there is no independent logical connection between these two concepts, i.e. temperature - and time_stamp. - - In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_id, - which is the independent variable vector against which eventually dozens of channels of data are logged. - Not only are these channels logged they should ideally also be self-descriptive in that these channels have - pulse_id as the independent variable but we do not wish to duplicate this information all the time but - reference it. - - Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the - symbol depends_on but this is easily to be confused with depends_on that is used for instances of - :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming - applications to understand that the here build correlations are conceptually different ones. - - This issue should be discussed further by the NeXus community. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time. -type: group -NXevent_data_apm(NXobject): - 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. - delta_time(NX_NUMBER): - unit: NX_TIME - doc: | - Delta time array which resolves for each pulse_id the time difference - between when that pulse was issued and start_time. - - In summary, using start_time, end_time, delta_time, pulse_id_offset, - and pulse_id exactly specifies the connection between when a pulse was - issued relative to start and absolute in UTC. - dimensions: - rank: 1 - dim: (p,) - pulse_id_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to name the first pulse to know if there is an - offset of the identifiers to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - pulse_id_offset and cardinality. For example if identifier run from - -2 to 3 the value for pulse_id_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where pulse_id_offset is 1 and 0 respectively. - pulse_id(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier that contextualizes how the detector and pulser of an atom probe - instrument follows a sequence of pulses to trigger field evaporation. - - The pulse_id is used to associate thus an information about time - when quantities have been collected via sampling. - - In virtually all cases the pulser is a blackbox. Depending on how the - instrument is configured during a measurement the target - values and thus also the actual values may change. - - Maybe the first part of the experiment is run at a certain pulse fraction but thereafter - the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, pulse_id is then an equally - long vector which stores the set of events (e.g. pulsing events) when that value was - measured. - - This may cause several situations: In the case that e.g. the pulse_fraction is never changed - and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the pulse_id e.g. 0 to indicate that the pulse_fraction was set - at the beginning and it was maintained constant during the measurement. - If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a - vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of pulse_id are then [0, 99999] respectively. - dimensions: - rank: 1 - dim: (p,) - instrument(NXinstrument_apm): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3c8ca2583c2145004aa0cfa43def0e327bd25076c246b0f288380ea0b9fbcc82 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time. -# -# -# -# -# Base class to store state and (meta)data of events over the course of an atom probe experiment. -# -# Having at least one instance for an instance of NXapm is recommended. -# -# This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs -# of atom probe research. Against static and dynamic quantities are split to avoid a duplication -# of information. Specifically, the time interval considered is the entire time -# starting at start_time until end_time during which we assume the pulser triggered named pulses. -# These pulses are identified via the pulse_id field. The point in time when each was issued -# is specified via the combination of start_time and delta_time. -# -# Which temporal granularity is adequate depends on the situation and research question. -# Using a model which enables a collection of events offers the most flexible way to cater for -# both atom probe experiments or simulation. To monitor the course of an ion extraction experiment -# (or simulation) it makes sense to track time explicitly via time stamps or implicitly -# via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event -# identifier. -# -# As set and measured quantities typically change over time and we do not yet know during the -# measurement which of the events have associated (molecular) ions that will end up in the -# reconstructed volume, we must not document quantities as a function of the evaporation_id but -# as a function of the (pulsing) identifier_event. -# -# Conceptually and technically NeXus currently stores tensorial information as arrays of values -# (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores -# a set of temperature values but that field when used somewhere is a concept. However, that -# concept has no information at which point in time these temperatures were taken. -# An existent functional relationship between the two concepts is not defined. -# -# However, a correct interpretation of the temperature values demands knowledge about what is -# the independent quantity on which temperature depends on or according to which frequency -# temperature values were sampled. -# In NeXus there are two approaches which cope with such correlations: -# One is :ref:`NXdata` where the attribute signal specifies the correlation. -# The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against -# (dependent signal) and independent quantities into an own group. -# In many cases this additional grouping is not desired though. -# -# One naive solution typically employed is then to store the independent variable values via a second -# vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). -# However, there is no independent logical connection between these two concepts, i.e. temperature -# and time_stamp. -# -# In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_id, -# which is the independent variable vector against which eventually dozens of channels of data are logged. -# Not only are these channels logged they should ideally also be self-descriptive in that these channels have -# pulse_id as the independent variable but we do not wish to duplicate this information all the time but -# reference it. -# -# Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the -# symbol depends_on but this is easily to be confused with depends_on that is used for instances of -# :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming -# applications to understand that the here build correlations are conceptually different ones. -# -# This issue should be discussed further by the NeXus community. -# -# -# -# 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. -# -# -# -# -# Delta time array which resolves for each pulse_id the time difference -# between when that pulse was issued and start_time. -# -# In summary, using start_time, end_time, delta_time, pulse_id_offset, -# and pulse_id exactly specifies the connection between when a pulse was -# issued relative to start and absolute in UTC. -# -# -# -# -# -# -# -# Integer used to name the first pulse to know if there is an -# offset of the identifiers to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# pulse_id_offset and cardinality. For example if identifier run from -# -2 to 3 the value for pulse_id_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where pulse_id_offset is 1 and 0 respectively. -# -# -# -# -# Identifier that contextualizes how the detector and pulser of an atom probe -# instrument follows a sequence of pulses to trigger field evaporation. -# -# The pulse_id is used to associate thus an information about time -# when quantities have been collected via sampling. -# -# In virtually all cases the pulser is a blackbox. Depending on how the -# instrument is configured during a measurement the target -# values and thus also the actual values may change. -# -# Maybe the first part of the experiment is run at a certain pulse fraction but thereafter -# the pulse_fraction is changed. In this case the field pulse_fraction is a vector which -# collects all measured values of the pulse_fraction, pulse_id is then an equally -# long vector which stores the set of events (e.g. pulsing events) when that value was -# measured. -# -# This may cause several situations: In the case that e.g. the pulse_fraction is never changed -# and also exact details not interesting, one stores the set value for the pulse_fraction -# and a single value for the pulse_id e.g. 0 to indicate that the pulse_fraction was set -# at the beginning and it was maintained constant during the measurement. -# If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a -# vector with two values one for the first and another one for the value from the 100000-th -# pulse onwards. The values of pulse_id are then [0, 99999] respectively. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml deleted file mode 100644 index b423b02492..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ /dev/null @@ -1,286 +0,0 @@ -category: base -doc: | - Base class to store state and (meta)data of events for electron microscopy. - - Event-related (meta)data, typically measured datasets like images and spectra. - To avoid repetitively storing static instrument-related metadata, - the dynamic (meta)data that typically changes for each image and spectrum - is split from the static (meta)data. - - Which temporal granularity is adequate to log events depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - - Electron microscopes are dynamic. Scientists often report that microscopes - *perform differently* across sessions. That *they* perform differently from - one day or another. In some cases, root causes for performance differences - are unclear. Users of the instrument may consider such conditions impractical, - or *too poor*, and thus abort their session. Alternatively, users may try to - bring the microscope into a state where conditions are considered better - or of whatever high enough quality for starting or continuing the measurement. - - In all these use cases it is useful to have a mechanism whereby time-dependent - data of the instrument state can be stored and documented in an representation - that facilitates interoperability. This is the idea behind this base class. - - :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly - whatever is considered a time interval during which the instrument is - considered stable enough for allowing any working on tasks with it. - Examples of such tasks are the collecting of data (images and spectra) or - the calibrating the instrument or individual of its components. Users may wish to take - only a single scan or image and complete their session thereafter. - Alternatively, users are working for much longer time at the instrument, - perform recalibrations in between and take several scans (of different - ROIs on the specimen), or they explore the state of the microscope for - service or maintenance tasks. - - :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: - - * Firstly, via a header section whose purpose is to contextualize - and identify the event instance in time. - * Secondly, via a data and metadata section where individual data - collections can be stored in a standardized representation. - - We are aware of the fact that given the variety how an electron microscope - is used, there is a need for a flexible and adaptive documentation system. - At the same time we are also convinced though that just because one has - different requirements for some specific aspect under the umbrella of settings - to an electron microscope, this does not necessarily warrant that one has to - cook up an own data schema. - - Instead, the electron microscopy community should work towards reusing schema - components as frequently as possible. This will enable that there is at all - not only a value of harmonizing electron microscopy research content but also - there is a technical possibility to build services around such harmonized data. - - 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 a stack of spectra. Having to deal with instabilities is a common theme in - electron microscopy practice. Numerical protocols can be used during data - post-processing to correct for some of the instabilities. - A few exemplar references provide an overview on the subject: - - * `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 (digital twin), 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 and ions, or detector noise models. - This also warrants to document the time-dependent details of individual components - of the microscope via the here implemented class :ref:`NXevent_data_em`. -type: group -NXevent_data_em(NXobject): - 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 users wish 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. - identifier_event(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of a specific state and setting of the microscope. - identifier_sample(NX_CHAR): - unit: NX_UNITLESS - doc: | - The name of the sample to resolve ambiguities. - type(NX_CHAR): - 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 for which there is at the moment no other place. - - In the long run such free-text field description should be avoided as - it is difficult to machine-interpret. Instead, an enumeration should - be used. - (NXuser): - (NXinstrument_em): - (NXimage): - (NXspectrum): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ab7fcd4482d84b1a491b17d7985199287f979dd3f253d941dd6318c428e09db -# -# -# -# -# -# Base class to store state and (meta)data of events for electron microscopy. -# -# Event-related (meta)data, typically measured datasets like images and spectra. -# To avoid repetitively storing static instrument-related metadata, -# the dynamic (meta)data that typically changes for each image and spectrum -# is split from the static (meta)data. -# -# Which temporal granularity is adequate to log events depends on the situation and -# research question. Using a model which enables a collection of events offers -# the most flexible way to cater for both experiments with controlled electron -# beams in a real microscope or the simulation of such experiments or -# individual aspects of such experiments. -# -# Electron microscopes are dynamic. Scientists often report that microscopes -# *perform differently* across sessions. That *they* perform differently from -# one day or another. In some cases, root causes for performance differences -# are unclear. Users of the instrument may consider such conditions impractical, -# or *too poor*, and thus abort their session. Alternatively, users may try to -# bring the microscope into a state where conditions are considered better -# or of whatever high enough quality for starting or continuing the measurement. -# -# In all these use cases it is useful to have a mechanism whereby time-dependent -# data of the instrument state can be stored and documented in an representation -# that facilitates interoperability. This is the idea behind this base class. -# -# :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly -# whatever is considered a time interval during which the instrument is -# considered stable enough for allowing any working on tasks with it. -# Examples of such tasks are the collecting of data (images and spectra) or -# the calibrating the instrument or individual of its components. Users may wish to take -# only a single scan or image and complete their session thereafter. -# Alternatively, users are working for much longer time at the instrument, -# perform recalibrations in between and take several scans (of different -# ROIs on the specimen), or they explore the state of the microscope for -# service or maintenance tasks. -# -# :ref:`NXevent_data_em` serves the harmonization and documentation of these cases: -# -# * Firstly, via a header section whose purpose is to contextualize -# and identify the event instance in time. -# * Secondly, via a data and metadata section where individual data -# collections can be stored in a standardized representation. -# -# We are aware of the fact that given the variety how an electron microscope -# is used, there is a need for a flexible and adaptive documentation system. -# At the same time we are also convinced though that just because one has -# different requirements for some specific aspect under the umbrella of settings -# to an electron microscope, this does not necessarily warrant that one has to -# cook up an own data schema. -# -# Instead, the electron microscopy community should work towards reusing schema -# components as frequently as possible. This will enable that there is at all -# not only a value of harmonizing electron microscopy research content but also -# there is a technical possibility to build services around such harmonized data. -# -# 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 a stack of spectra. Having to deal with instabilities is a common theme in -# electron microscopy practice. Numerical protocols can be used during data -# post-processing to correct for some of the instabilities. -# A few exemplar references provide an overview on the subject: -# -# * `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 (digital twin), 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 and ions, or detector noise models. -# This also warrants to document the time-dependent details of individual components -# of the microscope via the here implemented class :ref:`NXevent_data_em`. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval started. -# -# If users wish 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. -# -# -# -# -# Identifier of a specific state and setting of the microscope. -# -# -# -# -# The name of the sample to resolve ambiguities. -# -# -# -# -# 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 for which there is at the moment no other place. -# -# In the long run such free-text field description should be avoided as -# it is difficult to machine-interpret. Instead, an enumeration should -# be used. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml deleted file mode 100644 index 6c212b2205..0000000000 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ /dev/null @@ -1,233 +0,0 @@ -category: base -doc: | - Base class for a set of components equipping an instrument with FIB capabilities. - - Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped - with sufficient ion having sufficient momentum to remove material in a controlled - manner. - - The fact that an electron microscope with FIB capabilities achieves these functionalities - via a second component (aka the ion gun) that has its own relevant control circuits, - focusing lenses, and other components, warrants the definition of 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. -type: group -NXibeam_column(NXcomponent): - ion_source(NXsource): - doc: | - The source which creates the ion beam. - name(NX_CHAR): - doc: | - Given name/alias for the ion gun. - emitter_type(NX_CHAR): - 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(NX_CHAR): - 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+. - flux(NX_NUMBER): - unit: NX_ANY - doc: | - Average/nominal flux - brightness(NX_NUMBER): - unit: NX_ANY - doc: | - Average/nominal brightness - - # \@units: A/cm*sr - # NEW ISSUE: (at which location?). - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - Charge current - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Ion acceleration voltage upon source exit and - entering the vacuum flight path. - ion_energy_profile(NX_NUMBER): - unit: NX_ENERGY - doc: | - To be defined more specifically. Community suggestions are welcome. - - # NEW ISSUE: details about the life/up-time of the source relevant from maintenance point of view - (NXlens_em): - (NXaperture): - (NXmonochromator): - (NXsensor): - (NXactuator): - (NXdeflector): - (NXbeam): - doc: | - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - :ref:`NXtransformations` should be used to specify the location or position - at which details about the ion beam are probed. - (NXcomponent): - - # for further ideas and comments inspect version - # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 86c441c7f4d445f37b8c4ae1016a33cdf35a84568ba67f97a19b6fe564d43de6 -# -# -# -# -# -# -# Base class for a set of components equipping an instrument with FIB capabilities. -# -# Focused-ion-beam (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. The beam is controlled such that it is intense, focused, and equipped -# with sufficient ion having sufficient momentum to remove material in a controlled -# manner. -# -# The fact that an electron microscope with FIB capabilities achieves these functionalities -# via a second component (aka the ion gun) that has its own relevant control circuits, -# focusing lenses, and other components, warrants the definition of 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 flux -# -# -# -# -# Average/nominal brightness -# -# -# -# -# -# Charge current -# -# -# -# -# Ion acceleration voltage upon source exit and -# entering the vacuum flight path. -# -# -# -# -# To be defined more specifically. Community suggestions are welcome. -# -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the ion beam. -# -# :ref:`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.yaml b/contributed_definitions/nyaml/NXimage.yaml deleted file mode 100644 index 5ce740a061..0000000000 --- a/contributed_definitions/nyaml/NXimage.yaml +++ /dev/null @@ -1,1086 +0,0 @@ -category: base -doc: | - Base class for reporting a set of images representing specializations of NXdata. - - The most commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Colloquially, an image is understood as a discretized representation of intensity distribution - detected or simulated for some ROI. When discretized with regular Euclidean tilings, the terms - pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal - or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. - For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually more appropriate when working with such tilings. - - Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). - - Point coordinates identify the location of the barycenter. - - For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal - (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. - Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations: - - * `FFTW by M. Frigo and S. G. Johnson `_ - * `Intel MKL by the Intel Co. `_ - * `cuFFT by the NVidia Co. `_ - * `NFFT by the TU Chemnitz group `_ for non-equispaced computations - - Users are strongly advised to inspect carefully which specific conventions their library uses - to enable storing and modifying the implementation of their code such that the serialized - representations as they are detailed here for NeXus match. - - It is often the case that several images are combined using processing. In this case, - the number of images which are combined into collections is not necessarily the same - for each collection. The NXimage base class addresses this logical distinction - through the notation of indices_image and indices_group concepts. - That is indices_image are always counting from offset in increments of one - as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, indices_group are not required to be contiguous. - -# set of frequently made specializations of NXdata instances for images -symbols: - n_img: | - Number of images in the stack, for stacks the slowest dimension. - n_k: | - Number of image points along the slow dimension (k equivalent to z). - n_j: | - Number of image points along the fast dimension (j equivalent to y). - n_i: | - Number of image points along the fastest dimension (i equivalent to x). -type: group -NXimage(NXobject): - (NXprocess): - doc: | - Details how NXdata instance were processed from detector readings/raw data. - input(NXnote): - doc: | - Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` - instances in this :ref:`NXimage` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *context* therein adds context. - context(NX_CHAR): - doc: | - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - detector_identifier(NX_CHAR): - doc: | - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - (NXprogram): - doc: | - Program used for processing. - image_1d(NXdata): - doc: | - One-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 1 - dim: (n_i,) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 1 - dim: (n_i,) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 1 - dim: (n_i,) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 1 - dim: (n_i,) - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - image_2d(NXdata): - doc: | - Two-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 2 - dim: (n_j, n_i) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 2 - dim: (n_j, n_i) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 2 - dim: (n_j, n_i) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 2 - dim: (n_j, n_i) - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - image_3d(NXdata): - doc: | - Three-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 3 - dim: (n_k, n_j, n_i) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 3 - dim: (n_k, n_j, n_i) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 3 - dim: (n_k, n_j, n_i) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 3 - dim: (n_k, n_j, n_i) - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - stack_1d(NXdata): - doc: | - Collection of one-dimensional images. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 2 - dim: (n_img, n_i) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 2 - dim: (n_img, n_i) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 2 - dim: (n_img, n_i) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 2 - dim: (n_img, n_i) - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_image(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Image identifier - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - stack_2d(NXdata): - doc: | - Collection of two-dimensional images. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 3 - dim: (n_img, n_j, n_i) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 3 - dim: (n_img, n_j, n_i) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 3 - dim: (n_img, n_j, n_i) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 3 - dim: (n_img, n_j, n_i) - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_image(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - stack_3d(NXdata): - doc: | - Collection of three-dimensional images. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 4 - dim: (n_img, n_k, n_j, n_i) - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 4 - dim: (n_img, n_k, n_j, n_i) - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 4 - dim: (n_img, n_k, n_j, n_i) - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imag fields if values are stored as interleaved complex numbers. - dimensions: - rank: 4 - dim: (n_img, n_k, n_j, n_i) - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_image(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: (n_img,) - \@long_name(NX_CHAR): - doc: | - Image identifier - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fastest dimension. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60acbd1a10e09aa265edc132f5ba7aa0a721aa2cd5e32f9f5520fd33e9b528db -# -# -# -# -# -# -# -# -# Number of images in the stack, for stacks the slowest dimension. -# -# -# -# -# Number of image points along the slow dimension (k equivalent to z). -# -# -# -# -# Number of image points along the fast dimension (j equivalent to y). -# -# -# -# -# Number of image points along the fastest dimension (i equivalent to x). -# -# -# -# -# Base class for reporting a set of images representing specializations of NXdata. -# -# The most commonly used scanning methods are supported. That is one-, -# two-, three-dimensional ROIs discretized using regular Euclidean tilings. -# -# Colloquially, an image is understood as a discretized representation of intensity distribution -# detected or simulated for some ROI. When discretized with regular Euclidean tilings, the terms -# pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal -# or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. -# For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term -# (image) point is eventually more appropriate when working with such tilings. -# -# Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). -# -# Point coordinates identify the location of the barycenter. -# -# For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. -# Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal -# (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. -# Different libraries use different representations and encoding of the images. -# Details can be found in the respective sections of the typical FFT libraries documentations: -# -# * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ -# * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ -# * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ -# * `NFFT by the TU Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations -# -# Users are strongly advised to inspect carefully which specific conventions their library uses -# to enable storing and modifying the implementation of their code such that the serialized -# representations as they are detailed here for NeXus match. -# -# It is often the case that several images are combined using processing. In this case, -# the number of images which are combined into collections is not necessarily the same -# for each collection. The NXimage base class addresses this logical distinction -# through the notation of indices_image and indices_group concepts. -# That is indices_image are always counting from offset in increments of one -# as each image is its own entity. By contrast, a group may contain no, or several images. -# Consequently, indices_group are not required to be contiguous. -# -# -# -# Details how NXdata instance were processed from detector readings/raw data. -# -# -# -# Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` -# instances in this :ref:`NXimage` were loaded during parsing. -# -# Possibility to document from which specific other serialized resource as the source -# pieces of information were processed when using NeXus as a semantic file format -# to serialize that information differently. -# -# The group in combination with an added field *context* therein adds context. -# -# -# -# Reference to a location inside the artifact that points to the specific group of values -# that were processed if the artifacts contains several groups of values and thus -# further resolving of ambiguities is required. -# -# -# -# -# -# Link or name of an :ref:`NXdetector` instance with which the data were -# collected. -# -# -# -# -# Program used for processing. -# -# -# -# -# -# One-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Two-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Three-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of one-dimensional images. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of two-dimensional images. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of three-dimensional images. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imag fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinstrument_apm.yaml b/contributed_definitions/nyaml/NXinstrument_apm.yaml deleted file mode 100644 index 567345cfc0..0000000000 --- a/contributed_definitions/nyaml/NXinstrument_apm.yaml +++ /dev/null @@ -1,672 +0,0 @@ -category: base -doc: | - Base class to document an instrument used for atom probe microscopy. - - Inheriting from NXinstrument, this base class is designed to offer the same concepts about - instrument-centric metadata to be used in two places inside NXapm without demanding that - the application definition needs to define the concepts in two places as maintaining this is - prone to errors. This base class implements the key design idea behind the NXapm application - definition in that we would like to offer a design where all (meta)data which over the course - of a measurement remain static can be stored only once and without polluting the application - definition with another group with concepts that should be used for storing (meta)data about - the instrument during events that happen during the course of the measurement. - - This design was inspired by NXem and electron microscopy where typically the instrument is - used in sessions and dozens of logical sets of data are collected under not necessarily always - the same instrument conditions. We do not want to repeat therefore the static (meta)data, as - this is redundant storage by virtue of design. The typical example is an electron microscope - where hundreds of images are taken and all static instrument data stored with each image. - This makes sense in cases when the image is used as a digital artifact that is exchanged across - different software applications or research data management systems but as in NeXus there - is either all information bundled into one artifact or there is a coordinating master artifact - that references related artifacts there is no point to store hundreds of times that always the - same microscope with the same lens setup was used to collect these images. - -# One could use an NXnote or reference to another NeXus file where these static (meta)data -# are stored but then referencing this in an application definition would demand to make such -# file required, while NXinstrument_apm can be used directly for the static and the dynamic -# or volatile (meta)data. -type: group -NXinstrument_apm(NXinstrument): - type(NX_CHAR): - doc: | - Which type of instrument. - enumeration: - open_enum: true - items: [Inspico, 3DAP, LAWATAP, LEAP 3000 Si, LEAP 3000X Si, LEAP 3000 HR, LEAP 3000X HR, LEAP 4000 Si, LEAP 4000X Si, LEAP 4000 HR, LEAP 4000X HR, LEAP 5000 XS, LEAP 5000 XR, LEAP 5000 R, EIKOS, EIKOS-UV, LEAP 6000 XR, LEAP INVIZO, Photonic AP, TeraSAT, TAPHR, Modular AP, Titanium APT, Extreme UV APT] - fabrication(NXfabrication): - - # (NXcsg): - # doc: | - # Possibility to include a detailed computational geometry description of the instrument. - location(NX_CHAR): - doc: | - Location of the lab or place where the instrument is installed. Using GEOREF is - preferred. - reflectron(NXcomponent): - doc: | - Device which reduces ToF differences of ions in ToF experiments. - - For atom probe the reflectron can be considered an energy compensation device. - Such a device can be realized technically for example with a Poschenrieder lens. - - Consult the following U.S. patents for further details: - - * 3863068 and 6740872 for the reflectron - * 8134119 for the curved reflectron - applied(NX_BOOLEAN): - doc: | - Was the reflectron used? - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The maximum voltage applied to the reflectron, relative to system ground. - decelerate_electrode(NXlens_em): - doc: | - A counter electrode of the LEAP 6000 series atom probes. - - # counter_electrodes being optional WO2016171675A1 - # 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. - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Acceleration voltage - - # 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. - signal_amplitude(NX_FLOAT): - unit: NX_CURRENT - 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. - dimensions: - rank: 1 - dim: (p,) - mcp_efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - CRunHeader.fMcpEfficiency - mesh_efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - CRunHeader.fMeshEfficiency - - # model, serial_number, manufacturer_name all inherited from NXdetector base class - pulser(NXcomponent): - doc: | - Laser- and/or voltage-pulsing device to trigger ion removal. - - # technical design - fabrication(NXfabrication): - pulse_mode(NX_CHAR): - doc: | - Detail whereby ion extraction is triggered methodologically. - enumeration: - open_enum: true - items: [laser, voltage, laser_and_voltage] - - # the example of how the IFES APT TC's HDF format deals with such data - # conceptually, concepts are mixed into superconcepts interleaved tuple with - # different units: "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 - pulse_frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency with which the pulser fire(s). - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - pulse_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - 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. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - - # example of a conditional requirement that can be dealt with rigorously by OWL but not by NeXus! - # as either pulse_voltage is required in an application definition but then that - # existence constraint is independent of other values. - pulse_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Pulsed voltage, in laser pulsing mode this field can be omitted. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - pulse_number(NX_UINT): - unit: NX_UNITLESS - doc: | - Absolute number of pulses starting from the beginning of the experiment. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - - # eventually equivalent to pulse_id within NXevent_data_apm - standing_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. Otherwise, the - standing voltage applied to the sample, relative to system ground. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - (NXsource): - doc: | - Atom probe microscopes use controlled laser, voltage, or a combination of - pulsing strategies to trigger ion extraction via exciting and eventual field evaporation - field emission of ion at the specimen surface. - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength of the radiation emitted by the source. - power(NX_FLOAT): - unit: NX_POWER - doc: | - Nominal power of the laser source while illuminating the specimen. - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Average energy of the laser at peak of each pulse. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - (NXbeam): - doc: | - Details about specific positions along the laser beam - which illuminates the (atom probe) specimen. - incidence_vector(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the measurement - how the laser beam shines on the specimen, i.e. the mean vector - is parallel to the laser propagation direction. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - pinhole_position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the measurement - where the laser beam exits the focusing optics. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id - spot_position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - \@logged_against(NX_CHAR): - doc: | - Path to pulse_id in an instance of :ref:`NXevent_data_apm`. - (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. - stage(NXmanipulator): - temperature_sensor(NXsensor): - value(NX_FLOAT): - doc: | - CRunHeader.CAnalysis.fSpecimenTemperature - - # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM - analysis_chamber(NXcomponent): - flight_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - pressure_sensor(NXsensor): - measurement(NX_CHAR): - enumeration: [pressure] - value(NX_FLOAT): - unit: NX_PRESSURE - doc: | - CRunHeader.CLasHeader.fAnalysisPressure - buffer_chamber(NXcomponent): - load_lock_chamber(NXcomponent): - getter_pump(NXpump): - roughening_pump(NXpump): - turbomolecular_pump(NXpump): - comment(NX_CHAR): - doc: | - Free-text field for additional comments. - control(NXcollection): - doc: | - Relevant quantities during a measurement with a LEAP system as were - suggested by `T. Blum et al. `_. - evaporation_control(NX_CHAR): - doc: | - Parameter set typically in the GUI of the control software which - defines the rules and control loops whereby the pulser and other - components of the instrument are controlled during evaporation. - target_detection_rate(NX_NUMBER): - unit: NX_ANY - doc: | - Control parameter set typically in the GUI relevant to assure that - the instrument internally controls its settings such to assure a - significant yet not too high ion influx on the detector to avoid - detection losses. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ead34ef26b0915a0bcf618442df2ae1ece1b9a924fdf7fc2f8c9e82386c7afea -# -# -# -# -# -# -# Base class to document an instrument used for atom probe microscopy. -# -# Inheriting from NXinstrument, this base class is designed to offer the same concepts about -# instrument-centric metadata to be used in two places inside NXapm without demanding that -# the application definition needs to define the concepts in two places as maintaining this is -# prone to errors. This base class implements the key design idea behind the NXapm application -# definition in that we would like to offer a design where all (meta)data which over the course -# of a measurement remain static can be stored only once and without polluting the application -# definition with another group with concepts that should be used for storing (meta)data about -# the instrument during events that happen during the course of the measurement. -# -# This design was inspired by NXem and electron microscopy where typically the instrument is -# used in sessions and dozens of logical sets of data are collected under not necessarily always -# the same instrument conditions. We do not want to repeat therefore the static (meta)data, as -# this is redundant storage by virtue of design. The typical example is an electron microscope -# where hundreds of images are taken and all static instrument data stored with each image. -# This makes sense in cases when the image is used as a digital artifact that is exchanged across -# different software applications or research data management systems but as in NeXus there -# is either all information bundled into one artifact or there is a coordinating master artifact -# that references related artifacts there is no point to store hundreds of times that always the -# same microscope with the same lens setup was used to collect these images. -# -# -# -# Which type of instrument. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Location of the lab or place where the instrument is installed. Using GEOREF is -# preferred. -# -# -# -# -# Device which reduces ToF differences of ions in ToF experiments. -# -# For atom probe the reflectron can be considered an energy compensation device. -# Such a device can be realized technically for example with a Poschenrieder lens. -# -# Consult the following U.S. patents for further details: -# -# * 3863068 and 6740872 for the reflectron -# * 8134119 for the curved reflectron -# -# -# -# Was the reflectron used? -# -# -# -# -# The maximum voltage applied to the reflectron, relative to system ground. -# -# -# -# -# -# A counter electrode of the LEAP 6000 series atom probes. -# -# -# -# -# -# A local electrode guiding the ion flight path. -# Also called counter or extraction electrode. -# -# -# -# Acceleration voltage -# -# -# -# -# -# -# Detector for taking raw time-of-flight and ion/hit impact positions data. -# -# -# -# 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. -# -# -# -# -# -# -# -# CRunHeader.fMcpEfficiency -# -# -# -# -# CRunHeader.fMeshEfficiency -# -# -# -# -# -# -# Laser- and/or voltage-pulsing device to trigger ion removal. -# -# -# -# -# -# Detail whereby ion extraction is triggered methodologically. -# -# -# -# -# -# -# -# -# -# -# Frequency with which the pulser fire(s). -# -# -# -# Path to pulse_id -# -# -# -# -# -# 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. -# -# -# -# Path to pulse_id -# -# -# -# -# -# -# Pulsed voltage, in laser pulsing mode this field can be omitted. -# -# -# -# Path to pulse_id -# -# -# -# -# -# Absolute number of pulses starting from the beginning of the experiment. -# -# -# -# Path to pulse_id -# -# -# -# -# -# -# Direct current voltage between the specimen and the (local electrode) in -# the case of local electrode atom probe (LEAP) instrument. Otherwise, the -# standing voltage applied to the sample, relative to system ground. -# -# -# -# Path to pulse_id -# -# -# -# -# -# Atom probe microscopes use controlled laser, voltage, or a combination of -# pulsing strategies to trigger ion extraction via exciting and eventual field evaporation -# field emission of ion at the specimen surface. -# -# -# -# The wavelength of the radiation emitted by the source. -# -# -# -# -# Nominal power of the laser source while illuminating the specimen. -# -# -# -# -# Average energy of the laser at peak of each pulse. -# -# -# -# Path to pulse_id -# -# -# -# -# -# Details about specific positions along the laser beam -# which illuminates the (atom probe) specimen. -# -# -# -# Track time-dependent settings over the course of the measurement -# how the laser beam shines on the specimen, i.e. the mean vector -# is parallel to the laser propagation direction. -# -# -# -# Path to pulse_id -# -# -# -# -# -# Track time-dependent settings over the course of the measurement -# where the laser beam exits the focusing optics. -# -# -# -# Path to pulse_id -# -# -# -# -# -# Track time-dependent settings over the course of the -# measurement where the laser hits the specimen. -# -# -# -# Path to pulse_id in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# CRunHeader.CAnalysis.fSpecimenTemperature -# -# -# -# -# -# -# -# -# The space inside the atom probe along which ions pass nominally -# when they leave the specimen and travel to the detector. -# -# -# -# -# -# -# -# -# -# -# CRunHeader.CLasHeader.fAnalysisPressure -# -# -# -# -# -# -# -# -# -# -# -# Free-text field for additional comments. -# -# -# -# -# Relevant quantities during a measurement with a LEAP system as were -# suggested by `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. -# -# -# -# Parameter set typically in the GUI of the control software which -# defines the rules and control loops whereby the pulser and other -# components of the instrument are controlled during evaporation. -# -# -# -# -# Control parameter set typically in the GUI relevant to assure that -# the instrument internally controls its settings such to assure a -# significant yet not too high ion influx on the detector to avoid -# detection losses. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinstrument_em.yaml b/contributed_definitions/nyaml/NXinstrument_em.yaml deleted file mode 100644 index 480a6cdb7d..0000000000 --- a/contributed_definitions/nyaml/NXinstrument_em.yaml +++ /dev/null @@ -1,409 +0,0 @@ -category: base -doc: | - Base class for instrument-related details of a real or simulated electron microscope. - - For collecting data and experiments which are simulations of an electron - microscope (or such session) use the :ref:`NXem` application definition and - the :ref:`NXevent_data_em` groups it provides. - - This base class implements the concept of :ref:`NXem` whereby (meta)data are distinguished - whether these typically change during a session (dynamic) or not (static metadata). - This design allows to store e.g. hardware related concepts only once instead of demanding - that each image or spectrum from the session needs to be stored also with the static metadata. -type: group -NXinstrument_em(NXinstrument): - name(NX_CHAR): - doc: | - Given name of the microscope at the hosting institution. - This is an alias. Examples could be NionHermes, Titan, JEOL, - Gemini, etc. - location(NX_CHAR): - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - type(NX_CHAR): - exists: recommended - doc: | - Different types of electron microscopes exist: - - * sem, a scanning electron microscope without focused-ion beam capabilities - * fib, a scanning electron microscope with focused-ion beam capabilities - irrespective whether these were used or not - * tem, a transmission electron microscope - - NXem is one joint data model that can be used to document research that is performed - with several of these types of microscopes (SEM, TEM, or FIB). The NXem data model - stresses that these types of instruments despite having several differences are still all - electron beamlines with which to probe electron and/or ion matter interaction and in fact - in practice have many similarities in how they are used, the components, they contain, etc. - - This field can be used in research data management systems for enabling a categorization - or tagging of experiments without having to analyze if groups like NXibeam_column are present - (which would indicate type is fib) or if certain lens configurations or instrument models are used - which suggests the microscope is a scanning (sem) or transmission electron microscope (tem): - enumeration: [sem, fib, tem] - (NXfabrication): - (NXebeam_column): - (NXibeam_column): - - # (NXpbeam_column) for adding laser pulsing capabilities (NXsource + x) - (NXoptical_system_em): - (NXdetector): - 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. - scan_controller(NXscanbox_em): - stageID(NXmanipulator): - doc: | - Stages in an electron microscope are multi-functional devices. - - Stages enable experimentalists the application of controlled external stimuli - on the specimen. Modern stages realize a hierarchy of components. - A multi-axial tilt rotation holder is a good example where the control of - each degree of freedom is technically implemented via providing instances - of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating - and positioning of the specimen. - - The physical process of mounting a specimen on a stage in practice often - comes with an own hierarchy of fixtures to bridge e.g. length scales technically. - An example from atom probe microscopy is that researchers may work - with wire samples which are clipped into a larger fixing unit to enable - careful specimen handling. Alternatively, a microtip is a silicon post - upon which e.g. an atom probe specimen is mounted. Multiple of such microtips - are then grouped into a microtip array to conveniently enable loading of multiple - specimens into the instrument with fewer operations. There are further scenarios - typically encountered related to mounting and locating specimens inside an - electron microscope, a few examples follow: - - * A nanoparticle on a copper grid. The copper grid is the holder. - This grid itself is fixed to a stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. A typical - example are in-situ experiments using e.g. the tools of `Protochips `_. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes `_ - * `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 `_ - - # see for complicated positioning tools like an eucentric five-axis table stage in an SEM - # https://www.nanotechnik.com/e5as.html - design(NX_CHAR): - 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 - alias(NX_CHAR): - doc: | - Free-text field to give a term how that a stage_lab at this level of the - stage_lab hierarchy is commonly referred to. Examples could be stub, - puck, carousel, microtip, clip, holder, etc. - - # the pragmatic view for the majority of published datasets and EM images - # only tilt and position values are reported but the coordinate systems and conventions - # used in which these were defined are often not reported in the associated scientific publications - # this can be interpreted as that position values and tilts are only meaningful for those users - # in a particular narrow community which work with that particular microscope - tilt1(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this tilt1 value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - tilt is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - \@comment(NX_CHAR): - doc: | - Discouraged free-text field to provide details about how to interpret tilt1. - tilt2(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this tilt2 value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - tilt is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - \@comment(NX_CHAR): - doc: | - Discouraged free-text field to provide details about how to interpret tilt2. - rotation(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this rotation value can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - rotation is defined explicitly using instances of :ref:`NXtransformations` and - respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - \@comment(NX_CHAR): - doc: | - Discouraged free-text field to provide details about how to interpret rotation. - position(NX_NUMBER): - unit: NX_LENGTH - doc: | - The interpretation of these position values can be contextualized via the comment - attribute. However, it is better to describe the reference frame in which the - position values are defined explicitly using instances of :ref:`NXtransformations` - and respective instances of :ref:`NXcoordinate_system`. Especially when this - NXinstrument_em base class is used in an application definition like NXem. - dimensions: - rank: 1 - dim: (3,) - nanoprobeID(NXmanipulator): - doc: | - In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically - frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and - relocated portions of the specimen that have been cut off during site-specific lift-outs - and specimen preparation. - - # https://nano.oxinst.com/nanomanipulators. - (NXpump): - (NXsensor): - (NXactuator): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 44a122ac268435f4c6c6449db045720f4c0204c9d4881665c3bd497416d80529 -# -# -# -# -# -# Base class for instrument-related details of a real or simulated electron microscope. -# -# For collecting data and experiments which are simulations of an electron -# microscope (or such session) use the :ref:`NXem` application definition and -# the :ref:`NXevent_data_em` groups it provides. -# -# This base class implements the concept of :ref:`NXem` whereby (meta)data are distinguished -# whether these typically change during a session (dynamic) or not (static metadata). -# This design allows to store e.g. hardware related concepts only once instead of demanding -# that each image or spectrum from the session needs to be stored also with the static metadata. -# -# -# -# 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. -# -# -# -# -# Different types of electron microscopes exist: -# -# * sem, a scanning electron microscope without focused-ion beam capabilities -# * fib, a scanning electron microscope with focused-ion beam capabilities -# irrespective whether these were used or not -# * tem, a transmission electron microscope -# -# NXem is one joint data model that can be used to document research that is performed -# with several of these types of microscopes (SEM, TEM, or FIB). The NXem data model -# stresses that these types of instruments despite having several differences are still all -# electron beamlines with which to probe electron and/or ion matter interaction and in fact -# in practice have many similarities in how they are used, the components, they contain, etc. -# -# This field can be used in research data management systems for enabling a categorization -# or tagging of experiments without having to analyze if groups like NXibeam_column are present -# (which would indicate type is fib) or if certain lens configurations or instrument models are used -# which suggests the microscope is a scanning (sem) or transmission electron microscope (tem): -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# Stages in an electron microscope are multi-functional devices. -# -# Stages enable experimentalists the application of controlled external stimuli -# on the specimen. Modern stages realize a hierarchy of components. -# A multi-axial tilt rotation holder is a good example where the control of -# each degree of freedom is technically implemented via providing instances -# of e.g. :ref:`NXpositioner` or :ref:`NXactuator` that achieve the rotating -# and positioning of the specimen. -# -# The physical process of mounting a specimen on a stage in practice often -# comes with an own hierarchy of fixtures to bridge e.g. length scales technically. -# An example from atom probe microscopy is that researchers may work -# with wire samples which are clipped into a larger fixing unit to enable -# careful specimen handling. Alternatively, a microtip is a silicon post -# upon which e.g. an atom probe specimen is mounted. Multiple of such microtips -# are then grouped into a microtip array to conveniently enable loading of multiple -# specimens into the instrument with fewer operations. There are further scenarios -# typically encountered related to mounting and locating specimens inside an -# electron microscope, a few examples follow: -# -# * A nanoparticle on a copper grid. The copper grid is the holder. -# This grid itself is fixed to a stage. -# * An atom probe specimen fixed in a stub. In this case the stub can be -# considered the holder, while the cryostat temperature control unit is -# a component of the stage. -# * For in-situ experiments with e.g. chips with read-out electronics -# as actuators, the chips are again placed in a larger unit. A typical -# example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. -# * Other examples are (quasi) in-situ experiments where experimentalists -# anneal or deform the specimen via e.g. in-situ tensile testing machines -# which are mounted on the specimen holder. -# -# For specific details and inspiration about stages in electron microscopes: -# -# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ -# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ -# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ -# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) -# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) -# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) -# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ -# -# -# -# -# Principal design of the stage. -# -# Exemplar terms could be side_entry, top_entry, -# single_tilt, quick_change, multiple_specimen, -# bulk_specimen, double_tilt, tilt_rotate, -# heating_chip, atmosphere_chip, -# electrical_biasing_chip, liquid_cell_chip -# -# -# -# -# Free-text field to give a term how that a stage_lab at this level of the -# stage_lab hierarchy is commonly referred to. Examples could be stub, -# puck, carousel, microtip, clip, holder, etc. -# -# -# -# -# -# The interpretation of this tilt1 value can be contextualized via the comment -# attribute. However, it is better to describe the reference frame in which the -# tilt is defined explicitly using instances of :ref:`NXtransformations` and -# respective instances of :ref:`NXcoordinate_system`. Especially when this -# NXinstrument_em base class is used in an application definition like NXem. -# -# -# -# Discouraged free-text field to provide details about how to interpret tilt1. -# -# -# -# -# -# The interpretation of this tilt2 value can be contextualized via the comment -# attribute. However, it is better to describe the reference frame in which the -# tilt is defined explicitly using instances of :ref:`NXtransformations` and -# respective instances of :ref:`NXcoordinate_system`. Especially when this -# NXinstrument_em base class is used in an application definition like NXem. -# -# -# -# Discouraged free-text field to provide details about how to interpret tilt2. -# -# -# -# -# -# The interpretation of this rotation value can be contextualized via the comment -# attribute. However, it is better to describe the reference frame in which the -# rotation is defined explicitly using instances of :ref:`NXtransformations` and -# respective instances of :ref:`NXcoordinate_system`. Especially when this -# NXinstrument_em base class is used in an application definition like NXem. -# -# -# -# Discouraged free-text field to provide details about how to interpret rotation. -# -# -# -# -# -# The interpretation of these position values can be contextualized via the comment -# attribute. However, it is better to describe the reference frame in which the -# position values are defined explicitly using instances of :ref:`NXtransformations` -# and respective instances of :ref:`NXcoordinate_system`. Especially when this -# NXinstrument_em base class is used in an application definition like NXem. -# -# -# -# -# -# -# -# -# In contrast to the stage, the nanoprobe is an additional manipulator that is a specifically -# frequently found component of FIB/SEM instruments. A nanoprobe is used to pick up and -# relocated portions of the specimen that have been cut off during site-specific lift-outs -# and specimen preparation. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml b/contributed_definitions/nyaml/NXinteraction_volume_em.yaml deleted file mode 100644 index ec8fe7dcf4..0000000000 --- a/contributed_definitions/nyaml/NXinteraction_volume_em.yaml +++ /dev/null @@ -1,92 +0,0 @@ -category: base -doc: | - Base class to describe the volume of interaction for particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle-resolved sets of trajectories. - - Explicit or implicit descriptions of the geometry of this - interaction volume 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 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 flux through - an imaginary control surface (the iso-surface) 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. `_ - * `J. F. Ziegler et al. `_ -type: group -NXinteraction_volume_em(NXobject): - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aaed5462265171d4bd795348fcd1907519dfa4b05b484b9457cdd10661855ace -# -# -# -# -# -# Base class to describe the volume of interaction for particle-matter interaction. -# -# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam -# interaction simulations can be used to qualify and (or) quantify the shape of -# the interaction volume. Results of such simulations can be summary statistics -# or single-particle-resolved sets of trajectories. -# -# Explicit or implicit descriptions of the geometry of this -# interaction volume 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 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 flux through -# an imaginary control surface (the iso-surface) 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>`_ -# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ -# -# -# -# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml deleted file mode 100644 index f5a353d4f1..0000000000 --- a/contributed_definitions/nyaml/NXion.yaml +++ /dev/null @@ -1,184 +0,0 @@ -category: base -doc: | - Base class for documenting the set of atoms of a (molecular) ion. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivec_max: | - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - n_ranges: | - Number of mass-to-charge-state-ratio range intervals for ion type. -type: group -NXion(NXatom): - id(NX_CHAR): - doc: | - A unique identifier whereby such an ion can be referred to - via the service offered as described in id_type. - id_type(NX_CHAR): - doc: | - How can the identifier be resolved? - enumeration: [inchi] - ion_type(NX_UINT): - unit: NX_UNITLESS - doc: | - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: (n_ivec_max,) - nuclide_list(NX_UINT): - unit: NX_UNITLESS - doc: | - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - dimensions: - rank: 2 - dim: (n_ivec_max, 2) - mass_to_charge_range(NX_NUMBER): - unit: NX_ANY - doc: | - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - dimensions: - rank: 2 - dim: (n_ranges, 2) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a1dc78983139da8e01cd046802c165bc548480ccfb287e40c9bd4e1f188aa59a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). -# -# -# -# -# Number of mass-to-charge-state-ratio range intervals for ion type. -# -# -# -# -# Base class for documenting the set of atoms of a (molecular) ion. -# -# -# -# A unique identifier whereby such an ion can be referred to -# via the service offered as described in id_type. -# -# -# -# -# How can the identifier be resolved? -# -# -# -# -# -# -# -# Ion type (ion species) identifier. -# -# The identifier zero is reserved for the special unknown ion type. -# -# -# -# -# Vector of nuclide hash values. -# -# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# encode the number of protons :math:`Z` and the number of neutrons :math:`N` -# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. -# -# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. -# The first column specifies the nuclide mass number, i.e. using the hashvalues -# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no -# isotope-specific information about the element encoded is relevant. -# The second row specifies the number of protons :math:`Z` or 0. -# The value 0 in this case documents a placeholder or that no element-specific -# information is relevant. -# Taking a carbon-14 nuclide as an example the mass number is 14. -# That is encoded as a value pair (14, 6) as one row of the table. -# -# Therefore, this notation is the typical superscribed nuclide mass number -# and subscripted number of protons element notation e.g. :math:`^{14}C`. -# The array is stored matching the order of nuclide_hash. -# -# -# -# -# -# -# -# -# Associated lower (mqmin) and upper (mqmax) bounds of the -# mass-to-charge-state ratio interval(s) [mqmin, mqmax] -# (boundaries inclusive). This field is primarily of interest -# for documenting :ref:`NXprocess` steps of indexing a -# ToF/mass-to-charge state histogram. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml deleted file mode 100644 index 9c8ff4d151..0000000000 --- a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml +++ /dev/null @@ -1,310 +0,0 @@ -category: application -doc: | - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, or vibropolishing. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXlab_electro_chemo_mechanical_preparation(NXobject): - (NXentry): - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXlab_electro_chemo_mechanical_preparation] - workflow_step_id(NX_UINT): - doc: | - Sequence index that logically arranges this step along a workflow. - (NXsample): - exists: ['min', '1', 'max', '1'] - (NXuser): - exists: ['min', '1', 'max', 'unbounded'] - grinding_machine(NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - serial_number(NX_CHAR): - GRINDING_STEP(NXprocess): - nameType: any - 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(NX_CHAR): - doc: | - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - - # enumeration: [plate] - # controlled vocabulary items - abrasive_medium(NX_CHAR): - 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(NX_CHAR): - 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(NX_CHAR): - doc: | - Qualitative statement how the revelation of the machine was configured. - - If the rotation was controlled manually e.g. by turning knobs on the machine, - 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: [manual, fixed, programmed] - force_control(NX_CHAR): - 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: [manual, fixed, programmed] - time_control(NX_CHAR): - doc: | - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. - enumeration: [manual, fixed, programmed] - rotation(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Turns per unit time. - - # rotation_history(NX_NUMBER): - force(NX_NUMBER): - unit: NX_ANY - doc: | - Force exerted on the sample to press it into the abrasive. - - # force-history(NX_NUMBER): - time(NX_NUMBER): - unit: NX_TIME - doc: | - Seconds - removal: - doc: | - Qualitative statement how the material removal was characterized. - enumeration: [estimated, measured] - thickness_reduction(NX_NUMBER): - unit: NX_LENGTH - doc: | - How thick a layer was removed. - - # 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): - nameType: any - 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): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aa119311fb760e095cbdd1c65e066392aae7d4bf5f7e951c81f9e6d97a11e479 -# -# -# -# -# -# -# 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, or vibropolishing. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Sequence index that logically arranges this step along a workflow. -# -# -# -# -# -# -# -# -# -# -# -# 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 on the machine, -# 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/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml deleted file mode 100644 index 75a625e6f4..0000000000 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ /dev/null @@ -1,151 +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. -type: group -NXlab_sample_mounting(NXobject): - (NXentry): - - # by default for application definitions 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] - (NXsample): - exists: ['min', '1', 'max', '1'] - (NXuser): - exists: ['min', '1', 'max', 'unbounded'] - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - - # (NXlab_mounting_machine): - mounting_machine(NXfabrication): - vendor: - model: - serial_number: - exists: recommended - mounting_method: - doc: | - Qualitative statement how the sample was mounted. - enumeration: [cold_mounting, hot_mounting] - embedding_medium: - doc: | - Type of material. - enumeration: [resin, epoxy] - electrical_conductivity(NX_FLOAT): - unit: NX_ANY - doc: | - Electrical conductivity of the embedding medium. - - # 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 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? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4572e5c48086780e3988c719073d9c4c8782e28adae5590556ebb80ca01fee02 -# -# -# -# -# -# -# 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/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml deleted file mode 100644 index 8f8a42c2a6..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ /dev/null @@ -1,656 +0,0 @@ -category: application -doc: | - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen `_. - -# symbols: -# type: group -type: group -NXmicrostructure_gragles_config(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_gragles_config] - identifier_simulation(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXcollection): - exists: optional - doc: | - Programs and libraries representing the computational environment - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - discretization(NXmicrostructure): - - # [read_from_file] # poisson_voronoi_tessellation - # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE - # read the next three from input file - # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file - # Microstructure.SimID.10.uds - # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file - grid(NXnote): - doc: | - From which file should the microstructure be instantiated. - type: - file_name: - algorithm: - checksum: - edge_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! - sampling(NXparameters): - doc: | - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. - system(NX_UINT): - unit: NX_UNITLESS - doc: | - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. - geometry(NX_UINT): - unit: NX_UNITLESS - doc: | - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - - # 31 no more sampling - # 1 - simulation_control(NXparameters): - doc: | - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. - number_of_grains(NX_UINT): - unit: NX_UNITLESS - doc: | - The simulation stops if the total number of grains - becomes smaller than this criterion. - number_of_iterations(NX_UINT): - unit: NX_UNITLESS - doc: | - The simulation stops if more iterations than this criterion have been computed. - numerics(NXparameters): - doc: | - Configuration of numerical details of the solver. - - # use proper environment variable number_of_threads(NX_UINT): # obsolete set 01 16 - convolution_mode(NX_CHAR): - doc: | - Which type of convolution kernel and model is used. - enumeration: [gaussian, laplace, laplace_ritchardson] - time_slope(NX_FLOAT): - unit: NX_ANY - doc: | - Constant to calibrate the real time scaling of the simulation. - - # when taking the E_GAUSSIAN convolution mode set the TimeSlopeFactor explicitly here, default Miessen, Liesenjohann was 0.8359-\-> - # 0 - # 12991 # read from file - # discretization(NX_UINT) # 15 - # 15 - # domain_border_size(NX_UINT): # 7 - # 0 - # 0, Energies defined by misorientation, 1, GB Energies and mobilities clambed to 1.0 but uses sectors and Triplejunction mobilities, - # 2, GB Energies clambed to 0.3 or 0.6 / mobilities clambed to 1.0 - use Texture == false - # 0 # 0, E_NO_PROJECT, 1 E_TRIPLE_JUNCTION_DRAG_SINGLE (fixes outermost tj at, 2 empty) - # 1 # 0, E_ITERATIVE, 1, E_SQUARES - # 0.0 - # - grid_coarsement(NXparameters): - doc: | - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. - discretization(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. - is_active(NX_BOOLEAN): - doc: | - If true grid coarsement is active, otherwise it is not. - gradient(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. - - # the next only guru i.e. in C++ code configurable options - # 3 - # 2 - # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated - grain_boundary_mobility(NXparameters): - doc: | - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. - - # 0 - # 0 # - model(NX_CHAR): - doc: | - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. - enumeration: [rollett_holm] - - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - m_null(NX_FLOAT): - unit: NX_ANY - doc: | - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - c_one(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - # 7.5e-14 - c_two(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_2`. Typically 5. - c_three(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_3`. Typically 9. - grain_boundary_energy(NXparameters): - doc: | - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. - type(NX_CHAR): - doc: | - Fundamental type of assumption if energies are considered isotropic or not. - enumeration: [isotropic, anisotropic] - model(NX_CHAR): - doc: | - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. - enumeration: [read_shockley] - gamma(NX_FLOAT): - unit: NX_ANY - doc: | - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. - - # For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. - # 1.0 - # 0.01 - # - curvature_driving_force(NXparameters): - doc: | - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. - is_active(NX_BOOLEAN): - doc: | - If true the curvature_driving_force is considered, otherwise it is not. - stored_elastic_energy(NXparameters): - doc: | - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. - is_active(NX_BOOLEAN): - doc: | - If true the dislocation_driving_force is considered, otherwise it is not. - line_energy(NX_FLOAT): - unit: NX_ANY - doc: | - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. - magnetic_field(NXparameters): - doc: | - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. - is_active(NX_BOOLEAN): - doc: | - If true the magnetic_driving_force is considered, otherwise it is not. - - # MagneticField.xml - # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml - triple_line_mobility(NXparameters): - doc: | - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. - drag(NX_FLOAT): - unit: NX_ANY - doc: | - Assumed triple junction drag. - - # 1.0e10 - # isotropic, anisotropic - # 1 - # 1 25 - # - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4019d30d296ef8868c338bcbdbfd01d5c68a2e3e11d2bc66294c36161c18606c -# -# -# -# -# -# -# Application definition for configuring GraGLeS. -# -# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations -# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. -# CPU parallelization is achieved with OpenMP. -# -# The code has been implemented by C. Mießen in the group of G. Gottstein -# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. -# -# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# From which file should the microstructure be instantiated. -# -# -# -# -# -# -# -# -# The formulation of mean curvature flow in the GraGLeS model is scale invariant. -# Therefore, the discretization has to be scaled to the actual physical length -# of the simulation domain (ve, ROI). -# For GraGLeS the discretization is always a square or cubic axis-aligned -# bounding box with a regular tiling into material points -# (either squares or cubes respectively). -# -# Edge_length is the length of the entire domain along its edge not -# the length of the Wigner-Seitz cell about each material point! -# -# -# -# -# -# Configuration when snapshots of the system should be taken. -# -# Keep in mind that essentially geometry snapshot data store the -# polylines and polyhedra of all grains which can take substantial disk -# space. -# -# -# -# Generate a snapshot of the properties of the grains to follow -# the evolution of the microstructure every :math:`n`-th iteration. -# Setting zero causes that no property snapshots are taken. -# -# -# -# -# Generate a snapshot of the geometry of the entire grain boundary network -# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. -# -# -# -# -# -# -# Configuration when the simulation should be stopped in a controlled manner. -# Whichever criterion is fulfilled first triggers the controlled stop of -# and termination of GraGLeS. -# -# -# -# The simulation stops if the total number of grains -# becomes smaller than this criterion. -# -# -# -# -# The simulation stops if more iterations than this criterion have been computed. -# -# -# -# -# -# Configuration of numerical details of the solver. -# -# -# -# -# Which type of convolution kernel and model is used. -# -# -# -# -# -# -# -# -# -# Constant to calibrate the real time scaling of the simulation. -# -# -# -# -# -# -# Configuration of the grid coarsement algorithm whereby the representation -# of the system is continuously rediscretized such that on average grains -# are discretized with discretization many material points along each -# direction. -# -# Grid coarsement can reduce the computational costs substantially although -# it cannot be ruled out completely that the rediscretizing may have an effect -# on the system evolution. Without grid coarsement the total number of material -# points to consider stays the same throughout the simulation. -# -# -# -# Number of material points along each direction to discretize the -# average grain. The larger this value is chosen the finer the curvature -# details are that can be resolved but also the longer the simulation -# takes. -# -# -# -# -# If true grid coarsement is active, otherwise it is not. -# -# -# -# -# Fraction how strongly the number of grains has to reduce -# to trigger a grid coarsement step in an iteration. -# -# -# -# -# -# -# Physically-based model of the assumed mobility of the grain boundaries. -# -# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent -# especially as grain boundaries in reality are decorated with defects as a consequence of which -# the actual mobility is a combination of the mobility of the individual defects and the attached -# boundary patches. Grain boundaries have different degrees of microscopic freedom. -# Therefore, their mobility follows a distribution. -# -# -# -# -# Fundamental model how :math:`m` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. -# -# -# -# -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. -# -# -# -# -# -# Mobility scaling factor :math:`c_2`. Typically 5. -# -# -# -# -# Mobility scaling factor :math:`c_3`. Typically 9. -# -# -# -# -# -# Physically-based model of the assumed grain boundary surface energy. -# -# Like for the grain boundary mobility, defects cause a distribution of energies for the -# patches of which the boundary is composed. In practice a too complicated dependency -# of the energy and mobility model is observed as a function of the type and chemical -# decoration of the defects. Therefore, simplifying assumptions are typically made. -# -# -# -# Fundamental type of assumption if energies are considered isotropic or not. -# -# -# -# -# -# -# -# -# Fundamental model how :math:`\gamma` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# Mean grain boundary surface energy that is assumed a function of the -# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. -# This value factorizes the curvature_driving_force model. -# -# -# -# -# -# -# A continuum-scale curvature of an interface causes the interface to -# migrate towards the center of the curvature radius. -# -# -# -# If true the curvature_driving_force is considered, otherwise it is not. -# -# -# -# -# -# A continuum-scale difference of the stored elastic energy in dislocation -# configurations across a grain boundary can exert a driving force on the -# grain boundary such that the boundary migrates into the volume with the -# higher stored elastic energy. -# -# -# -# If true the dislocation_driving_force is considered, otherwise it is not. -# -# -# -# -# Prefactor :math:`0.5Gb^2` that factorizes the average -# stored elastic energy per length dislocation line. -# -# -# -# -# -# In case of an applied magnetic field, a difference of the magnetic -# susceptibility can exert a driving force on the grain boundary such that -# the boundary migrates into the volume with the higher magnetic energy. -# -# -# -# If true the magnetic_driving_force is considered, otherwise it is not. -# -# -# -# -# -# -# A triple line mediates the atomic arrangement differences between three -# interface patches. Therefore, the triple line is a defect that may not -# have the same mobility as adjoining grain boundaries and thus it may -# exert what can be conceptualized as a drag (resistance) to the motion -# of the adjoining interface patches. -# -# -# -# Assumed triple junction drag. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml deleted file mode 100644 index ecf900f0ec..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ /dev/null @@ -1,510 +0,0 @@ -category: application -doc: | - Application definition for documenting results with GraGLeS. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_summary_stats: | - The total number of summary statistic log entries. - n_grains: | - Number of grains in the computer simulation. - n_interfaces: | - Number of interfaces in the computer simulation. -type: group -NXmicrostructure_gragles_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_gragles_results] - - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - identifier_simulation(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXcollection): - exists: optional - doc: | - Programs and libraries representing the computational environment - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - sample_reference_frame(NXcoordinate_system): - type: - handedness: - origin: - x_alias: - x_direction: - y_alias: - y_direction: - z_alias: - z_direction: - spatiotemporalID(NXprocess): - nameType: partial - doc: | - Documentation of the spatiotemporal evolution - - # static quantities for which no change is modelled - # the typical lean summary statistics flattened - summary_statistics(NXprocess): - doc: | - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - kinetics(NXprocess): - exists: optional - doc: | - Evolution of the recrystallized volume fraction over time. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - dimensions: - rank: 1 - dim: (n_summary_stats,) - iteration(NX_INT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - number_of_crystals(NX_UINT): - unit: NX_UNITLESS - doc: | - How many crystals are distinguished. - Crystals are listed irrespective of the phase to which these are assigned. - dimensions: - rank: 1 - dim: (n_summary_stats,) - stress(NXprocess): - exists: optional - type: - doc: | - Which type of stress. - enumeration: [cauchy] - stress(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress tensor on the ROI. - dimensions: - rank: 3 - dim: (n_summary_stats, 3, 3) - strain(NXprocess): - exists: optional - type: - doc: | - Which type of strain. - strain(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external strain tensor on the ROI. - dimensions: - rank: 3 - dim: (n_summary_stats, 3, 3) - deformation_gradient(NXprocess): - exists: optional - type: - doc: | - Which type of deformation gradient. - enumeration: [piola] - value(NX_FLOAT): - unit: NX_ANY - doc: | - Applied deformation gradient tensor on the ROI. - dimensions: - rank: 3 - dim: (n_summary_stats, 3, 3) - magnetic_field(NXprocess): - exists: optional - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external magnetic field on the ROI. - dimensions: - rank: 3 - dim: (n_summary_stats, 3, 3) - electrical_field(NXprocess): - exists: optional - - # specify type of field - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external electrical field on the ROI. - dimensions: - rank: 3 - dim: (n_summary_stats, 3, 3) - - # the typically storage-costlier snapshot data - microstructureID(NXmicrostructure): - exists: ['min', '1', 'max', 'unbounded'] - nameType: partial - time(NX_NUMBER): - iteration(NX_INT): - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Simulated temperature for this snapshot. - grid(NXcg_grid): - exists: optional - crystal(NXmicrostructure_feature): - representation: - exists: recommended - number_of_crystals(NX_UINT): - number_of_phases(NX_UINT): - index_offset_crystal(NX_INT): - indices_crystal(NX_INT): - dimensions: - rank: 1 - dim: (n_grains,) - index_offset_phase(NX_INT): - indices_phase(NX_INT): - dimensions: - rank: 1 - dim: (n_grains,) - area(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_grains,) - volume(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_grains,) - interface(NXmicrostructure_feature): - exists: optional - representation(NX_CHAR): - exists: recommended - number_of_interfaces(NX_UINT): - index_offset_interface(NX_INT): - indices_interface(NX_INT): - dimensions: - rank: 1 - dim: (n_interfaces,) - indices_crystal(NX_INT): - unit: NX_UNITLESS - doc: | - One pair of indices_crystal values for each interface. - dimensions: - rank: 2 - dim: (n_interfaces, 2) - \@use_these(NX_CHAR): - relative_mobility(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Mobility times surface energy density of the interface normalized - to the maximum such product of the interface set. - dimensions: - rank: 1 - dim: (n_interfaces,) - area(NX_NUMBER): - dimensions: - rank: 1 - dim: (n_interfaces,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ce46d9c44dd5374e61f88bb2cb3a620e5b2c51e149e8d021a5969dbf58bc4b42 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of summary statistic log entries. -# -# -# -# -# Number of grains in the computer simulation. -# -# -# -# -# Number of interfaces in the computer simulation. -# -# -# -# -# Application definition for documenting results with GraGLeS. -# -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Documentation of the spatiotemporal evolution -# -# -# -# -# Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening in for practical reasons though in while -# running the simulation. Place used for storing descriptors from continuum mechanics -# and thermodynamics at the scale of the entire ROI. -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# Evolution of the physical time not to be confused with wall-clock time or -# profiling data. -# -# -# -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# How many crystals are distinguished. -# Crystals are listed irrespective of the phase to which these are assigned. -# -# -# -# -# -# -# -# -# -# Which type of stress. -# -# -# -# -# -# -# -# Applied external stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of strain. -# -# -# -# -# Applied external strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of deformation gradient. -# -# -# -# -# -# -# -# Applied deformation gradient tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Applied external magnetic field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external electrical field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Simulated temperature for this snapshot. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# One pair of indices_crystal values for each interface. -# -# -# -# -# -# -# -# -# -# Mobility times surface energy density of the interface normalized -# to the maximum such product of the interface set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml deleted file mode 100644 index fd9c63b266..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ /dev/null @@ -1,421 +0,0 @@ -category: application -doc: | - Application definition for the configuration of the legacy (micro)structure generator - developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. `_ - * `C. Mießen `_ - * `M. Kühbach `_ - * `M. Kühbach et al. `_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -symbols: - n_categories: | - How many texture components are distinguished, minimum is 1. - n_components: | - How many special texture components are distinguished if any. - n_ori: | - Number of discrete orientations that are distributed across the grains. -type: group -NXmicrostructure_imm_config(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_imm_config] - roi(NXparameters): - doc: | - The computational domain will be synthesized either as a square (for dimensionality = 2) - or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is - discretized into material points using either square pixel or cubic voxel as the tessellating - unit cells. - dimensionality(NX_POSINT): - doc: | - Two-dimensional or three-dimensional simulation. - enumeration: [2, 3] - discretization(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the number of material points per equivalent - discrete diameter of the arithmetic average sub-grain. - crystal_symmetry(NX_CHAR): - doc: | - Assumed space group of the material. - enumeration: [fcc, bcc, hcp] - - # PreferenceOrientations.txt - # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE - number_of_grains(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the number of grains. The actual domain size and grid will be configured - based on the choices for discretization, number_of_grains, and shape of these grains. - number_of_subgrains(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the average number of sub-grains per grain. - - # 0 is there another one if not remove - # 1 always one - # 1-\-> - # 1 - grain_shape(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - If available used to define the sequence of relative extent of grains along the y (first value) - and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, - the relative extent of the grains will be 1 one average along each axis (globulitic structure). - dimensions: - rank: 1 - dim: (2,) - - # 0.05 - # 1.0 - # remove 0 all the time 0.00 - # remove 0 all the time 0.00 - # - component_analysis(NXparameters): - exists: optional - doc: | - In texture research component analyses set on the idea that properties - of grains different based on orientation with certain regions in orientation - space show similar trends like a different average dislocation density - or orientation_spread. - component_name(NX_CHAR): - doc: | - The first entry is always the null model None which means that an orientation - is not categorized as a special component. Examples for special components are - Dillamore, Copper, Cube, Y, P and Q. - dimensions: - rank: 1 - dim: (n_categories,) - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - dimensions: - rank: 2 - dim: (n_components, 3) - theta(NX_FLOAT): - unit: NX_ANGLE - doc: | - Disorientation angle below which an orientation is categorized as one of the - components. - dimensions: - rank: 1 - dim: (n_components,) - dislocation_distribution(NXparameters): - doc: | - Dislocations are modelled as Rayleigh-distributed mean-field density that - can differ between but is constant within grains and sub-grains. - min_max_grain(NX_FLOAT): - unit: NX_ANY - doc: | - The minimum and the maximum dislocation density to distribute across grains. - dimensions: - rank: 2 - dim: (n_categories, 2) - min_max_subgrain(NX_FLOAT): - unit: NX_ANY - doc: | - The minimum and the maximum dislocation density to distribute across sub-grains. - dimensions: - rank: 2 - dim: (n_categories, 2) - - # 10.8e14# 10.8e14 - doc: | - The variance of the dislocation density distribution across the grains. - dimensions: - rank: 1 - dim: (n_categories,) - variance_subgrain(NX_FLOAT): - unit: NX_ANY - doc: | - The variance of the dislocation density distribution across the sub-grains. - dimensions: - rank: 1 - dim: (n_categories,) - orientation_distribution(NXparameters): - doc: | - Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation - of the (parent) grain and with optional Rayleigh-distributed scatter. - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - dimensions: - rank: 2 - dim: (n_ori, 3) - variance_subgrain(NX_FLOAT): - unit: NX_ANGLE - doc: | - The variance of the disorientation of the sub-grain to their parent grain. - dimensions: - rank: 1 - dim: (n_categories,) - - # what is with preference orientations? - # 1 # via OpenMP - # 1 - # 0.00 - # 1.00 - # 0.00 - # 1.00 - # -# -# -# -# -# -# -# How many texture components are distinguished, minimum is 1. -# -# -# -# -# How many special texture components are distinguished if any. -# -# -# -# -# Number of discrete orientations that are distributed across the grains. -# -# -# -# -# Application definition for the configuration of the legacy (micro)structure generator -# developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# The computational domain will be synthesized either as a square (for dimensionality = 2) -# or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is -# discretized into material points using either square pixel or cubic voxel as the tessellating -# unit cells. -# -# -# -# Two-dimensional or three-dimensional simulation. -# -# -# -# -# -# -# -# -# Target value for the number of material points per equivalent -# discrete diameter of the arithmetic average sub-grain. -# -# -# -# -# Assumed space group of the material. -# -# -# -# -# -# -# -# -# -# -# Target value for the number of grains. The actual domain size and grid will be configured -# based on the choices for discretization, number_of_grains, and shape of these grains. -# -# -# -# -# Target value for the average number of sub-grains per grain. -# -# -# -# -# -# If available used to define the sequence of relative extent of grains along the y (first value) -# and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, -# the relative extent of the grains will be 1 one average along each axis (globulitic structure). -# -# -# -# -# -# -# -# -# -# In texture research component analyses set on the idea that properties -# of grains different based on orientation with certain regions in orientation -# space show similar trends like a different average dislocation density -# or orientation_spread. -# -# -# -# The first entry is always the null model None which means that an orientation -# is not categorized as a special component. Examples for special components are -# Dillamore, Copper, Cube, Y, P and Q. -# -# -# -# -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# Disorientation angle below which an orientation is categorized as one of the -# components. -# -# -# -# -# -# -# -# -# Dislocations are modelled as Rayleigh-distributed mean-field density that -# can differ between but is constant within grains and sub-grains. -# -# -# -# The minimum and the maximum dislocation density to distribute across grains. -# -# -# -# -# -# -# -# -# The minimum and the maximum dislocation density to distribute across sub-grains. -# -# -# -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the grains. -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the sub-grains. -# -# -# -# -# -# -# -# -# Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. -# Orientations of the sub-grains are sampled by scattering the orientation -# of the (parent) grain and with optional Rayleigh-distributed scatter. -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# The variance of the disorientation of the sub-grain to their parent grain. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml deleted file mode 100644 index 72adcdc0ce..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ /dev/null @@ -1,329 +0,0 @@ -category: application -doc: | - Application definition for the results of the legacy (micro)structure generator developed - by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. `_ - * `C. Mießen `_ - * `M. Kühbach `_ - * `M. Kühbach et al. `_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -symbols: - n_edge: | - Number of material points along the edge of the square- or cube-shaped domain. - c: | - Number of crystals. -type: group -NXmicrostructure_imm_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_imm_results] - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program(NX_CHAR): - \@version(NX_CHAR): - \@url(NX_CHAR): - exists: recommended - environment(NXcollection): - exists: optional - doc: | - Programs and libraries representing the computational environment - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version(NX_CHAR): - microstructureID(NXmicrostructure): - nameType: partial - grid(NXcg_grid): - extent(NX_UINT): - cell_dimensions(NX_NUMBER): - structure(NXdata): - doc: | - Default plot showing the grid. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - indices_crystal(NX_INT): - unit: NX_UNITLESS - doc: | - Crystal identifier that was assigned to each material point. - - # either (n_edge, n_edge) or (n_edge, n_edge, n_edge) - z(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Material point barycenter coordinate along z direction. - dimensions: - rank: 1 - dim: (n_edge,) - \@long_name(NX_CHAR): - doc: | - Coordinate along z direction. - y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycenter coordinate along y direction. - dimensions: - rank: 1 - dim: (n_edge,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycenter coordinate along x direction. - dimensions: - rank: 1 - dim: (n_edge,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - crystals(NXmicrostructure_feature): - reference(NX_CHAR): - number_of_crystals(NX_UINT): - indices_crystal(NX_INT): - dimensions: - rank: 1 - dim: (c,) - area(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: (c,) - volume(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: (c,) - is_subgrain(NX_BOOLEAN): - exists: recommended - doc: | - True if the crystal is considered a sub-grain. - False if the crystal is considered a grain. - dimensions: - rank: 1 - dim: (c,) - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle orientation of each crystal. - dimensions: - rank: 2 - dim: (c, 3) - dislocation_density(NX_FLOAT): - unit: NX_ANY - doc: | - Mean-field dislocation density as a measure of the stored elastic energy - content that is stored in the dislocation network of this grain and related - defects within each crystal. - dimensions: - rank: 1 - dim: (c,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8a8ae246a82288cbe1dffe13e542acca67b88bdf48c0c56c9f2b33c300af7ad -# -# -# -# -# -# -# -# Number of material points along the edge of the square- or cube-shaped domain. -# -# -# -# -# Number of crystals. -# -# -# -# -# Application definition for the results of the legacy (micro)structure generator developed -# by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# Default plot showing the grid. -# -# -# -# -# -# -# -# Crystal identifier that was assigned to each material point. -# -# -# -# -# -# Material point barycenter coordinate along z direction. -# -# -# -# -# -# -# Coordinate along z direction. -# -# -# -# -# -# Material point barycenter coordinate along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Material point barycenter coordinate along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# True if the crystal is considered a sub-grain. -# False if the crystal is considered a grain. -# -# -# -# -# -# -# -# Bunge-Euler angle orientation of each crystal. -# -# -# -# -# -# -# -# -# Mean-field dislocation density as a measure of the stored elastic energy -# content that is stored in the dislocation network of this grain and related -# defects within each crystal. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_lens.yaml b/contributed_definitions/nyaml/NXoptical_lens.yaml deleted file mode 100644 index b6f7d986c5..0000000000 --- a/contributed_definitions/nyaml/NXoptical_lens.yaml +++ /dev/null @@ -1,309 +0,0 @@ -category: base -doc: | - Description of an optical lens. -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. -type: group -NXoptical_lens(NXcomponent): - type: - doc: | - Type of the lens (e.g. concave, convex etc.). - enumeration: - open_enum: true - items: [biconcave, plano-concave, convexo-concave, biconvex, plano-convex, concavo-convex, Fresnel lens] - chromatic(NX_BOOLEAN): - doc: | - Is it a chromatic lens? - lens_diameter(NX_NUMBER): - unit: NX_LENGTH - doc: | - Diameter of the lens. - 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): - unit: NX_LENGTH - doc: | - Thickness of the lens substrate at the optical axis. - index_of_refraction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the lens material. Specify at given - wavelength (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: (2, N_spectrum) - COATING(NXsample): - nameType: any - 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): - unit: NX_LENGTH - doc: | - Thickness of the coating. - index_of_refraction_coating(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: (2, N_spectrum_coating) - reflectance: - unit: NX_UNITLESS - doc: | - Reflectance of the lens at given spectral values. - dimensions: - rank: 1 - dim: (N_spectrum_RT,) - transmission: - unit: NX_UNITLESS - doc: | - Transmission of the lens at given spectral values. - dimensions: - rank: 1 - dim: (N_spectrum_RT,) - focal_length(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - 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). - dimensions: - rank: 1 - dim: (2,) - curvature_radius_FACE(NX_NUMBER): - nameType: partial - exists: recommended - unit: NX_LENGTH - 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_radius_front or curvature_radius_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(NX_NUMBER): - nameType: specified - unit: NX_UNITLESS - doc: | - Abbe number (or V-number) of the lens. - numerical_aperture(NX_NUMBER): - doc: | - The numerical aperture of the lens. - magnification(NX_FLOAT): - doc: | - Magnification of the lens - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ff3aacdecbd2c9293ac333fafe4799f9a696484027f8b97362b534b39fcea2de -# -# -# -# -# -# -# -# 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. -# -# -# -# Type of the lens (e.g. concave, convex etc.). -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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_radius_front or curvature_radius_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. -# -# -# -# -# The numerical aperture of the lens. -# -# -# -# -# Magnification of the lens -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml deleted file mode 100644 index 88e9c37b52..0000000000 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ /dev/null @@ -1,1963 +0,0 @@ -category: application -doc: | - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free-text descriptions, it is recommended to use English, as this ensures - the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. -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_measurements: | - Number of measurements (1st dimension of measured data arrays). 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. - -# 04/2024 -# Extension of the Draft Version (05/2023) of a NeXus application definition which -# serves as a template for various optical spectroscopy experiments -# TODO: -# - Add NXoptical_lens and NXwaveplate to NXinstrument? -# - Make polfilter_TYPE(NXcomponent) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. -# - Make spectralfilter_TYPE(NXcomponent) own base class -\-> extend NXfilter? and add them to NXinstrument. -# - Make offset angles for polar and azimuthal? -# - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? -# - Add optical elements and rework them: NXfiber, NXbeam_splitter, -# - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? -# - Is there something to describe the spot size? -# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" -# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more arbitrary shapes as elliptically? Maybe as well focus spot size? -# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed? -type: group -NXoptical_spectroscopy(NXobject): - (NXentry): - 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: [NXoptical_spectroscopy] - title: - exists: recommended - start_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise, the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - identifier_experiment: - exists: recommended - experiment_description: - exists: optional - doc: | - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. - experiment_type: - doc: | - Specify the type of the optical experiment. - - Use another term if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. - enumeration: - open_enum: true - items: [photoluminescence, transmission spectroscopy, reflection spectroscopy] - experiment_sub_type: - exists: optional - doc: | - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. - enumeration: - open_enum: true - items: [time resolved, imaging, pump-probe] - beam_ref_frame(NXcoordinate_system): - exists: optional - depends_on(NX_CHAR): - doc: | - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. - (NXtransformations): - doc: | - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. - sample_normal_ref_frame(NXcoordinate_system): - exists: optional - depends_on(NX_CHAR): - doc: | - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. - (NXtransformations): - doc: | - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation - (NXinstrument): - doc: | - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties - beam_TYPE(NXbeam): - nameType: partial - exists: ['min', '1', 'max', 'unbounded'] - doc: | - This can be used to describe properties of a photon beam. - A beam can be connected to components, via their - "inputs" and "outputs". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are actually measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) - parameter_reliability: - doc: | - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). - enumeration: [measured, nominal] - incident_wavelength(NX_NUMBER): - exists: recommended - incident_wavelength_spread(NX_NUMBER): - exists: recommended - incident_polarization(NX_NUMBER): - exists: recommended - extent(NX_FLOAT): - exists: recommended - associated_source(NX_CHAR): - exists: optional - doc: | - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light source can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser - beam_polarization_type: - exists: optional - enumeration: [linear, circular, elliptically, unpolarized] - linear_beam_sample_polarization(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. Note that the zero reference should be a direction vector for a - :ref:`reference_plane ` - normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. - This can be used if no definition of respective - coordinate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". - detector_TYPE(NXdetector): - nameType: partial - exists: ['min', '1', 'max', 'unbounded'] - detector_channel_type: - enumeration: [single-channel, multichannel] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: - open_enum: true - items: [CCD, photomultiplier, photodiode, avalanche-photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate] - raw_data(NXdata): - exists: recommended - doc: | - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - additional_detector_hardware: - exists: optional - doc: | - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). - device_information(NXfabrication): - exists: recommended - source_TYPE(NXsource): - nameType: partial - exists: recommended - type: - exists: recommended - enumeration: - open_enum: true - items: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Optical Laser, Laser, Dye-Laser, Broadband Tunable Light Source, Halogen lamp, LED, Mercury Cadmium Telluride, Deuterium Lamp, Xenon Lamp, Globar] - name: - exists: recommended - standard: - exists: optional - doc: | - If available, name/ID/norm of the light source standard. - device_information(NXfabrication): - exists: recommended - doc: | - Details about the device information. - associated_beam(NX_CHAR): - exists: recommended - doc: | - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - (NXmonochromator): - exists: recommended - device_information(NXfabrication): - exists: recommended - angle_reference_frame: - exists: recommended - doc: | - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible: - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam - - angle of in-plane sample rotation (direction along the sample's surface normal) - - An arbitrary reference frame can be defined by "reference_frames" - and used via "instrument/angle_sample_and_beam_TYPE" - enumeration: [beam centered, sample-normal centered] - omega(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between sample incident beam and sample surface. - twotheta(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between incident and detection beam - chi(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Sample tilt between sample normal, and the plane spanned by detection and - incident beam. - phi(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Inplane rotation of the sample, with rotation axis along sample normal. - angle_of_incidence(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - angle_of_detection(NX_NUMBER): - exists: optional - unit: NX_ANGLE - 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. - These two directions span the plane of detection. - angle_of_incident_and_detection_beam(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - angle_of_in_plane_sample_rotation(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - generic_beam_sample_angle_TYPE(NXtransformations): - nameType: partial - exists: recommended - doc: | - Set of transformations, describing the relative orientation of different - parts of the experiment (beams or sample). You may select one of the specified - angles for incident and detection beam or sample, and then use polar and azimuthal - angles to define the direction via spherical coordinates. - This allows consistent definition between different coordinate system. - You may refer to self defined coordinate system as well. - - - If "angle_reference_frame = beam centered", then this coordinate system is used: - McStas system (NeXus default) - (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - - i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and - the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` - is vertically oriented. - - If "angle_reference_frame = sample-normal centered", then this coordinate - system is used - z - math:`[0,0,1]` along sample surface normal - x - math:`[1,0,0]` defined by sample surface projected incident beam. - y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. - For this case, x may be ill defined, if the incident beam is perpendicular - to the sample surface. In this case, use the beam centered description. - type: - enumeration: [incident beam, detection beam, sample] - polar(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the y axis (polar rotation within the sample plane). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 1, 0]] - \@depends_on: - doc: | - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - azimuth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the z axis (azimuthal rotation within the sample plane). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, 1]] - \@depends_on: - enumeration: [offset_tilt] - lateral_focal_point_offset(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - (NXcomponent): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Optical components along the optical beam path. - - Every object which interacts or modifies optical beam properties, - may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - (NXoptical_lens): - exists: optional - doc: | - This is the optical element used to focus or collect light. This may - be a generic lens or microcope objectives which are used for the - Raman scattering process. - type: - enumeration: - open_enum: true - items: [objective, lens, glass fiber, none] - device_information(NXfabrication): - exists: optional - (NXwaveplate): - exists: optional - (NXoptical_window): - exists: optional - polfilter_TYPE(NXcomponent): - exists: optional - nameType: partial - doc: | - Polarization filter to prepare light to be measured or to be incident - on the sample. - Generic polarization filter properties may be implemented via NXfilter_pol - at a later stage. - filter_mechanism(NX_CHAR): - exists: optional - doc: | - Physical principle of the polarization filter used to create a - defined incident or scattered light state. - enumeration: - open_enum: true - items: [polarization by Fresnel reflection, birefringent polarizers, thin film polarizers, wire-grid polarizers] - specific_polarization_filter_type(NX_CHAR): - exists: optional - doc: | - Specific name or type of the polarizer used. - - Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... - device_information(NXfabrication): - exists: optional - spectralfilter_TYPE(NXcomponent): - exists: optional - nameType: partial - doc: | - Spectral filter used to modify properties of the scattered or incident light. - filter_type: - exists: optional - doc: | - Type of laser-line filter used to suppress the laser, if measurements - close to the laser-line are performed. - enumeration: - open_enum: true - long-pass filter: - doc: | - Blocks shorter wavelengths and transmits longer wavelengths. - short-pass filter: - doc: | - Blocks longer wavelengths and transmits shorter wavelengths. - notch filter: - doc: | - Blocks a narrow wavelength band while transmitting others. - reflection filter: - doc: | - Reflects certain wavelength ranges instead of absorbing them. - neutral density filter: - doc: | - Reduces light intensity uniformly across all wavelengths. - intended_use: - exists: optional - doc: | - Type of laser-line filter used to suppress the laser, if measurements - close to the laser-line are performed. - enumeration: - open_enum: true - items: [laser line cleanup, raylight line removal, spectral filtering, intensity manipulation] - filter_characteristics(NXdata): - exists: optional - doc: | - Properties of the spectral filter such as wavelength dependent transmission - or reflectivity. - \@characteristics_type: - exists: optional - doc: | - Which property is used to form the spectral properties of light, - i.e. transmission or reflection properties. - enumeration: [transmission, reflection] - device_information(NXfabrication): - exists: optional - (NXbeam_transfer_matrix_table): - exists: optional - doc: | - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. - sample_stage(NXmanipulator): - exists: optional - doc: | - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. - stage_type: - exists: optional - doc: | - Specify the type of the sample stage. - enumeration: - open_enum: true - items: [manual stage, scanning stage, liquid stage, gas cell, cryostat, heater] - transformations(NXtransformations): - exists: optional - doc: | - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. - beam_sample_relation: - exists: optional - doc: | - Description of relation of the beam with the sample. How does the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - This is redundant if a full orientation description is done via the - stage's "transformations" entry. - device_information(NXfabrication): - exists: optional - temperature_sensor(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [temperature] - type: - exists: optional - value(NX_FLOAT): - device_information(NXfabrication): - exists: optional - temp_control_TYPE(NXactuator): - nameType: partial - exists: optional - doc: | - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - cooler_or_heater: - exists: recommended - enumeration: [cooler, heater] - type: - exists: optional - doc: | - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - (NXpid_controller): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): - exists: optional - device_information(NXfabrication): - exists: recommended - doc: | - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - construction_year(NX_DATE_TIME): - exists: optional - software_TYPE(NXprogram): - nameType: partial - exists: recommended - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - \@version: - exists: recommended - 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: | - Description of the software by persistent resource, where the program, - code, script etc. can be found. - instrument_calibration_DEVICE(NXcalibration): - nameType: partial - exists: recommended - doc: | - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - device_path: - exists: recommended - doc: | - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - calibration_accuracy(NXdata): - exists: optional - doc: | - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - calibration_status(NX_CHAR): - exists: recommended - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - calibration_time. - enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] - calibration_time(NX_DATE_TIME): - exists: optional - doc: | - If calibration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - (NXdata): - exists: optional - doc: | - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. - wavelength_resolution(NXresolution): - exists: optional - doc: | - The overall resolution of the optical instrument. - physical_quantity: - enumeration: [wavelength] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Minimum distinguishable wavelength separation of peaks in spectra. - (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. - name: - sample_id: - exists: recommended - doc: | - Locally unique ID of the sample, used in the research institute or group. - physical_form: - exists: recommended - doc: | - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. - description: - exists: optional - doc: | - Free text description of the sample. - chemical_formula: - exists: recommended - 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: - 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'. - 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 timestamp when - the measured specimen surface was actively prepared. - history(NXhistory): - exists: recommended - doc: | - A set of activities that occurred to the sample prior to/during the experiment. - temperature_env(NXenvironment): - exists: recommended - doc: | - Sample temperature (either controlled or just measured). - temperature_nominal: - exists: optional - doc: | - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. - enumeration: - open_enum: true - items: [room temperature, liquid helium temperature, liquid nitrogen temperature] - temperature_sensor(NXsensor): - exists: recommended - doc: | - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - sample_heater(NXactuator): - exists: optional - doc: | - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - sample_cooler(NXactuator): - exists: optional - doc: | - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. - (NXenvironment): - exists: optional - doc: | - Arbitrary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperature description of the sample. - sample_medium: - exists: recommended - doc: | - Medium, in which the sample is placed. - enumeration: - open_enum: true - items: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water] - sample_medium_refractive_indices(NX_FLOAT): - exists: optional - unit: NX_UNITLESS - 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. - dimensions: - rank: 2 - dim: (2, N_spectrum) - thickness(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - 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. - thickness_determination: - exists: optional - doc: | - If a thickness if given, please specify how this thickness was estimated or - determined. - layer_structure: - exists: optional - 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. - sample_orientation: - exists: optional - doc: | - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. - substrate: - exists: recommended - doc: | - If the sample is grown or fixed on a substrate, specify this here by - a free text description. - (NXdata): - doc: | - Here generic types of data may be saved. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plottable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata - \@axes: - doc: | - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - \@signal: - doc: | - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - measurement_data_calibration_TYPE(NXprocess): - nameType: partial - exists: recommended - wavelength_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - Calibrated wavelength axis. - derived_parameters(NXprocess): - exists: optional - doc: | - Parameters that are derived from the measured data. - depolarization(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Light loss due to depolarization as a value in [0-1]. - dimensions: - rank: 3 - dim: (N_measurements, 1, N_spectrum) - jones_quality_factor(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Jones quality factor. - dimensions: - rank: 3 - dim: (N_measurements, 1, N_spectrum) - reflectivity(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Reflectivity. - dimensions: - rank: 3 - dim: (N_measurements, 1, N_spectrum) - transmittance(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Transmittance. - dimensions: - rank: 3 - dim: (N_measurements, 1, N_spectrum) - ANALYSIS_program(NXprogram): - nameType: partial - 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: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a80446e818774501708ee6369d01b2af414a8aecd636c635a53e51a9e636e6c2 -# -# -# -# -# -# -# -# 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 measurements (1st dimension of measured data arrays). 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. -# -# -# -# -# A general application definition of optical spectroscopy elements, which may -# be used as a template to derive specialized optical spectroscopy experiments. -# -# Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, -# reflectivity/transmission spectroscopy. -# -# A general optical experiment consists of (i) a light/photon source, (ii) a sample, -# (iii) a detector. -# -# For any free-text descriptions, it is recommended to use English, as this ensures -# the most FAIR (Findable, Accessible, Interoperable, and Reusable) representation of the information. -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise, the local time zone is assumed per ISO8601. -# -# It is required to enter at least one of both measurement times, either "start_time" or "end_time". -# -# -# -# -# Datetime of the end of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# It is required to enter at least one of both measurement times, either "start_time" or "end_time". -# -# -# -# -# -# An optional free-text description of the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such a free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn how far the -# current base classes need extension based on user feedback. -# -# -# -# -# Specify the type of the optical experiment. -# -# Use another term if none of these methods are suitable. You may specify -# fundamental characteristics or properties in the experimental sub-type. -# -# For Raman spectroscopy or ellipsometry use the respective specializations -# of NXoptical_spectroscopy. -# -# -# -# -# -# -# -# -# -# Specify a special property or characteristic of the experiment, which specifies -# the generic experiment type. -# -# -# -# -# -# -# -# -# -# -# This refers to the coordinate system along the beam path. The origin and -# base is defined at z=0, where the incident beam hits the sample at the surface. -# -# -# -# -# This is the default NeXus coordinate system (McStas), if the transformation -# does not change the coordinate system at all - i.e. it is unity. -# Otherwise, by this a respective transformation of the beam -# reference frame to the default reference frame could be made. i.e. -# exchange of x and z coordinate, rotation of respective coordinates -# towards each other. -# -# -# -# -# -# -# Link to transformations defining the sample-normal base coordinate system, -# which is defined such that the positive z-axis is parallel to the sample normal, -# and the x-y-plane lies inside the sample surface. -# -# -# -# -# Set of transformations, describing the orientation of the sample-normal coordinate system -# with respect to the beam coordinate system (.). -# -# -# -# -# -# Contact information and eventually details of at persons who -# performed the measurements. This can be for example the principal -# investigator or student. Examples are: name, affiliation, address, telephone -# number, email, role as well as identifiers such as orcid or similar. -# It is recommended to add multiple users if relevant. -# -# Due to data privacy concerns, there is no minimum requirement. -# If no user with specific name is allowed to be given, it is required to -# assign at least an affiliation -# -# -# -# -# Devices or elements of the optical spectroscopy setup described with its -# properties and general information. -# -# This includes for example: -# - The beam device's or instrument's model, company, serial number, construction year, etc. -# - Used software or code -# - Experiment descriptive parameters as reference frames, resolution, calibration -# - Photon beams with their respective properties such as angles and polarization -# - Various optical beam path devices, which interact, manipulate or measure optical beams -# - Characteristics of the medium surrounding the sample -# - "Beam devices" for a beam path description -# - Stages(NXmanipulator) -# - Sensors and actuators to control or measure sample or beam properties -# -# -# -# This can be used to describe properties of a photon beam. -# A beam can be connected to components, via their -# "inputs" and "outputs". -# -# It is required to define at least one incident beam which is incident -# to the sample. You may specify if this beam parameters are actually measured -# or just nominal. -# If this beam is the output of a source, chose the same -# name appendix as for the NXsource instance (e.g. TYPE=532nm) -# -# -# -# Select the reliability of the respective beam characteristics. Either, -# the parameters are measured via another device or method or just given -# nominally via the properties of a light source properties (532nm, 100mW). -# -# -# -# -# -# -# -# -# -# -# -# -# The path to the device which emitted this beam (light source or frequency doubler). -# -# This parameter is recommended, if the previous optical element is a photon source. -# In this way, the properties of the laser or light source can be described -# and associated. -# The beam should be named with the same appendix as the source, e.g., -# for TYPE=532nmlaser, there should be both a NXsource named -# "source_532nmlaser" and a NXbeam named "beam_532nmlaser". -# -# Example: /entry/instrument/source_532nmlaser -# -# -# -# -# -# -# -# -# -# -# -# -# Angle of the linear polarized light, with respect to a fixed arbitrary -# defined 0° position. Note that the zero reference should be a direction vector for a -# :ref:`reference_plane </NXbeam/TRANSFORMATIONS/reference_plane-field>` -# normal in an :ref:`NXtransformations` group within :ref:`NXbeam`. -# This can be used if no definition of respective -# coordinate systems for beam and sample normal is done. If coordinate systems -# are defined, refer to beam "incident_polarization". -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Contains the raw data collected by the detector before calibration. -# The data which is considered raw might change from experiment to experiment -# due to hardware pre-processing of the data. -# This field ideally collects the data with the lowest level of processing -# possible. -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# Specify respective hardware which was used for the detector. For -# example special electronics required for time-correlated single photon -# counting (TCSPC). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If available, name/ID/norm of the light source standard. -# -# -# -# -# Details about the device information. -# -# -# -# -# The path to a beam emitted by this source. -# Should be named with the same appendix, e.g., -# for TYPE=532nmlaser, there should as well be -# a NXbeam named "beam_532nmlaser" together with this source -# instance named "source_532nmlaser" -# -# Example: /entry/instrument/beam_532nmlaser -# -# -# -# -# -# -# -# -# Defines the reference frame which is used to describe the sample orientation -# with respect to the beam directions. -# -# A beam centered description is the default and uses 4 angles(similar to XRD): -# - Omega (angle between sample surface and incident beam) -# - 2Theta (angle between the transmitted beam and the detection beam) -# - Chi (sample tilt angle, angle between plane#1 and the surface normal, -# plane#1 = spanned by incidence beam and detection -# and detection. If Chi=0°, then plane#1 is the plane of -# incidence in reflection setups) -# - Phi (inplane rotation of sample, rotation axis is the samples -# surface normal) -# -# -# A sample normal centered description is as well possible: -# - angle of incidence (angle between incident beam and sample surface) -# - angle of detection (angle between detection beam and sample surface) -# - angle of incident and detection beam -# - angle of in-plane sample rotation (direction along the sample's surface normal) -# -# An arbitrary reference frame can be defined by "reference_frames" -# and used via "instrument/angle_sample_and_beam_TYPE" -# -# -# -# -# -# -# -# -# Angle between sample incident beam and sample surface. -# -# -# -# -# Angle between incident and detection beam -# -# -# -# -# Sample tilt between sample normal, and the plane spanned by detection and -# incident beam. -# -# -# -# -# Inplane rotation of the sample, with rotation axis along sample normal. -# -# -# -# -# Angle(s) of the incident beam vs. the normal of the bottom reflective -# (substrate) surface in the sample. These two directions span the plane -# of incidence. -# -# -# -# -# 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. -# These two directions span the plane of detection. -# -# -# -# -# Angle between the incident and detection beam. -# If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, -# then the setup is a reflection setup. -# If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam -# then the setup may be a light scattering setup. -# (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but -# the angle source-sample-detector is 90°) -# -# -# -# -# Angle of the inplane orientation of the sample. This might be an arbitrary, -# angle without specific relation to the sample symmetry, -# of the angle to a specific sample property (i.e. crystallographic axis or sample -# shape such as wafer flat) -# -# -# -# -# Set of transformations, describing the relative orientation of different -# parts of the experiment (beams or sample). You may select one of the specified -# angles for incident and detection beam or sample, and then use polar and azimuthal -# angles to define the direction via spherical coordinates. -# This allows consistent definition between different coordinate system. -# You may refer to self defined coordinate system as well. -# -# -# If "angle_reference_frame = beam centered", then this coordinate system is used: -# McStas system (NeXus default) -# (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) -# -# i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and -# the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` -# is vertically oriented. -# -# If "angle_reference_frame = sample-normal centered", then this coordinate -# system is used -# z - math:`[0,0,1]` along sample surface normal -# x - math:`[1,0,0]` defined by sample surface projected incident beam. -# y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. -# For this case, x may be ill defined, if the incident beam is perpendicular -# to the sample surface. In this case, use the beam centered description. -# -# -# -# -# -# -# -# -# -# -# Rotation about the y axis (polar rotation within the sample plane). -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to a transformation that places the sample surface -# into the origin of the arpes_geometry coordinate system. -# -# -# -# -# -# Rotation about the z axis (azimuthal rotation within the sample plane). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if there is a lateral offset on the sample surface, between the focal -# points of the incident beam and the detection beam. -# -# -# -# -# Optical components along the optical beam path. -# -# Every object which interacts or modifies optical beam properties, -# may be a component, e.g. Filter, Window, Beamsplitter, Photon Source, -# Detector, etc, -# -# -# -# -# This is the optical element used to focus or collect light. This may -# be a generic lens or microcope objectives which are used for the -# Raman scattering process. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Polarization filter to prepare light to be measured or to be incident -# on the sample. -# Generic polarization filter properties may be implemented via NXfilter_pol -# at a later stage. -# -# -# -# Physical principle of the polarization filter used to create a -# defined incident or scattered light state. -# -# -# -# -# -# -# -# -# -# -# Specific name or type of the polarizer used. -# -# Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston -# Polarizer... -# -# -# -# -# -# -# Spectral filter used to modify properties of the scattered or incident light. -# -# -# -# Type of laser-line filter used to suppress the laser, if measurements -# close to the laser-line are performed. -# -# -# -# Blocks shorter wavelengths and transmits longer wavelengths. -# -# -# Blocks longer wavelengths and transmits shorter wavelengths. -# -# -# Blocks a narrow wavelength band while transmitting others. -# -# -# Reflects certain wavelength ranges instead of absorbing them. -# -# -# Reduces light intensity uniformly across all wavelengths. -# -# -# -# -# -# Type of laser-line filter used to suppress the laser, if measurements -# close to the laser-line are performed. -# -# -# -# -# -# -# -# -# -# -# Properties of the spectral filter such as wavelength dependent transmission -# or reflectivity. -# -# -# -# Which property is used to form the spectral properties of light, -# i.e. transmission or reflection properties. -# -# -# -# -# -# -# -# -# -# -# -# Allows description of beam properties via matrices, which relate ingoing with -# outgoing beam properties. -# -# -# -# -# Sample stage (or manipulator) for positioning of the sample. This should -# only contain the spatial orientation of movement. -# -# -# -# Specify the type of the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# This allows a description of the stages relation or orientation and -# position with respect to the sample or beam, if an laboratory or -# an stage coordinate system is defined. -# -# -# -# -# Description of relation of the beam with the sample. How does the -# sample hit the beam, e.g. 'center of sample, long edge parallel -# to the plane of incidence'. -# This is redundant if a full orientation description is done via the -# stage's "transformations" entry. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Type of control for the sample temperature. Replace TYPE by "cryostat" or -# "heater" to specify it. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive -# -# -# -# -# -# -# -# -# -# General device information of the optical spectroscopy setup, if -# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). -# For custom build setups, this may be limited to the construction year. -# -# -# -# -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to control any parts of the optical spectroscopy setup. -# The uppercase TYPE should be replaced by a specification name, i.e. -# "software_detector" or "software_stage" to specify the respective -# program or software components. -# -# -# -# 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. -# -# -# -# -# Description of the software by persistent resource, where the program, -# code, script etc. can be found. -# -# -# -# -# -# -# Pre-calibration of an arbitrary device of the instrumental setup, which -# has the name DEVICE. You can specify here how, at which time by which method -# the calibration was done. As well the accuracy and a link to the calibration -# dataset. -# -# -# -# Path to the device, which was calibrated. -# Example: entry/instrument/DEVICE -# -# -# -# -# Provide data about the determined accuracy of the device, this may -# may be a single value or a dataset like wavelength error vs. wavelength etc. -# -# -# -# -# Was a calibration performed? If yes, when was it done? If the -# calibration time is provided, it should be specified in -# calibration_time. -# -# -# -# -# -# -# -# -# -# -# -# If calibration status is 'calibration time provided', specify the -# ISO8601 date when calibration was last performed before this -# measurement. UTC offset should be specified. -# -# -# -# -# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. -# This can be for example the instrument response function. -# -# -# -# -# -# The overall resolution of the optical instrument. -# -# -# -# -# -# -# -# -# -# Minimum distinguishable wavelength separation of peaks in spectra. -# -# -# -# -# -# -# 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. -# -# -# -# -# Locally unique ID of the sample, used in the research institute or group. -# -# -# -# -# State the form of the sample, examples are: -# thin film, single crystal, poly crystal, amorphous, single layer, -# multi layer, liquid, gas, pellet, powder. -# Generic properties of liquids or gases see NXsample properties. -# -# -# -# -# Free text description of the sample. -# -# -# -# -# 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'. -# -# -# -# -# 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 timestamp when -# the measured specimen surface was actively prepared. -# -# -# -# -# A set of activities that occurred to the sample prior to/during the experiment. -# -# -# -# -# Sample temperature (either controlled or just measured). -# -# -# -# If no sensor was available for the determination of temperature, selected -# a nominal value which represents approximately the situation of sample temperature. -# -# -# -# -# -# -# -# -# -# Temperature sensor measuring the sample temperature. -# This should be a link to /entry/instrument/manipulator/temperature_sensor. -# -# -# -# -# Device to heat the sample. -# This should be a link to /entry/instrument/manipulator/sample_heater. -# -# -# -# -# Device for cooling the sample (Cryostat, Airflow cooler, etc.). -# This should be a link to /entry/instrument/manipulator/cryostat. -# -# -# -# -# -# Arbitrary sample property which may be varied during the experiment -# and controlled by a device. Examples are pressure, voltage, magnetic field etc. -# Similar to the temperature description of the sample. -# -# -# -# Medium, in which the sample is placed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# (Measured) sample thickness. -# -# The information is recorded to qualify if the light used was likely -# able to shine through the sample. -# -# 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. -# -# -# -# -# If a thickness if given, please specify how this thickness was estimated or -# determined. -# -# -# -# -# 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. -# -# -# -# -# Specify the sample orientation, how is its sample normal oriented -# relative in the laboratory reference frame, incident beam reference -# frame. -# -# -# -# -# If the sample is grown or fixed on a substrate, specify this here by -# a free text description. -# -# -# -# -# -# Here generic types of data may be saved. This may refer to data derived -# from single or multiple raw measurements (i.e. several intensities are -# evaluated for different parameters: ellipsometry -> psi and delta) - -# i.e. non-raw data. -# As well plottable data may be stored/linked here, which provides the most suitable -# representation of the data (for the respective community). -# -# You may provide multiple instances of NXdata -# -# -# -# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) -# -# -# -# -# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) -# -# -# -# -# -# -# -# Calibrated wavelength axis. -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml deleted file mode 100644 index f9e3380c58..0000000000 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ /dev/null @@ -1,295 +0,0 @@ -category: base -doc: | - Base class for qualifying an electron optical system. -type: group -NXoptical_system_em(NXobject): - camera_length(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which is present between the specimen surface and the detector plane. - - | - xref: - spec: EMglossary - term: Camera Length - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The factor of enlargement of the apparent size, - not the physical size, of an object. - defocus(NX_NUMBER): - unit: NX_LENGTH - doc: | - The defocus aberration constant (oftentimes referred to as c_1_0). - See respective details in :ref:`NXaberration` class instances. - semi_convergence_angle(NX_NUMBER): - unit: NX_ANGLE - doc: - - | - The angle which is given by the semi-opening angle of the cone in a convergent - beam. - - | - xref: - spec: EMglossary - term: Convergence Angle - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - field_of_view(NX_NUMBER): - unit: NX_LENGTH - doc: | - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - working_distance(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which is determined along the optical axis within the column from (1) the - lower end of the final optical element between the source and the specimen stage; - to (2) the point where the beam is focused. - - | - xref: - spec: EMglossary - term: Working Distance - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - probe(NXcg_ellipsoid): - doc: | - Geometry of the cross-section formed when the primary beam shines onto the - specimen surface. - - # dimensions: - # rank: 2 - probe_current(NX_NUMBER): - unit: NX_CURRENT - doc: - - | - Electrical current which arrives at the specimen. - - | - xref: - spec: EMglossary - term: Probe Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - dose_management(NX_CHAR): - doc: | - Specify further details how incipient electron or ion dose was quantified - (using beam_current, probe_current). - - `Reference `_ discusses - an approach for (electron) dose monitoring in an electron microscope. - - The unit of the nominal dose rate is e-/(angstrom^2*s). - dose_rate(NX_NUMBER): - unit: 1/(angstrom^2*s) - doc: | - Nominal dose rate. - rotation(NX_NUMBER): - unit: NX_ANGLE - doc: | - In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated - on a helical path about the optical axis. This causes an image rotation whose strength - is affected by the magnification. - - Microscopes may be equipped with compensation methods (implemented in hardware - or software) that reduce but not necessarily eliminate this rotation. - - See `L. Reimer `_ for details. - focal_length(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which lies between the principal plane of the lens and the focal point - along the optical axis. - - | - xref: - spec: EMglossary - term: Focal Length - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - tilt_correction(NX_BOOLEAN): - doc: - - | - Details about an imaging setting used during acquisition to correct perspective - distortion when imaging a tilted surface or cross section. - - | - xref: - spec: EMglossary - term: Tilt Correction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 - dynamic_focus_correction(NX_BOOLEAN): - doc: - - | - Details about a dynamic focus correction used. - - | - xref: - spec: EMglossary - term: Dynamic Focus Correction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 - dynamic_refocusing(NX_CHAR): - doc: - - | - Details about a workflow used to keep the specimen in focus by automatic means. - - | - xref: - spec: EMglossary - term: Dynamic Refocusing - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f70f9651e027dbd19d14b17716bb0bbf83cf667b9b9361f8989be079ec7cc317 -# -# -# -# -# -# Base class for qualifying an electron optical system. -# -# -# -# Distance which is present between the specimen surface and the detector plane. -# -# This concept is related to term `Camera Length`_ of the EMglossary standard. -# -# .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 -# -# -# -# -# The factor of enlargement of the apparent size, -# not the physical size, of an object. -# -# -# -# -# The defocus aberration constant (oftentimes referred to as c_1_0). -# See respective details in :ref:`NXaberration` class instances. -# -# -# -# -# The angle which is given by the semi-opening angle of the cone in a convergent -# beam. -# -# This concept is related to term `Convergence Angle`_ of the EMglossary standard. -# -# .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 -# -# -# -# -# The extent of the observable parts of the specimen given the current -# magnification and other settings of the instrument. -# -# -# -# -# Distance which is determined along the optical axis within the column from (1) the -# lower end of the final optical element between the source and the specimen stage; -# to (2) the point where the beam is focused. -# -# This concept is related to term `Working Distance`_ of the EMglossary standard. -# -# .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 -# -# -# -# -# Geometry of the cross-section formed when the primary beam shines onto the -# specimen surface. -# -# -# -# -# -# Electrical current which arrives at the specimen. -# -# This concept is related to term `Probe Current`_ of the EMglossary standard. -# -# .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 -# -# -# -# -# Specify further details how incipient electron or ion dose was quantified -# (using beam_current, probe_current). -# -# `Reference <https://doi.org/10.1017/S1551929522000840>`_ discusses -# an approach for (electron) dose monitoring in an electron microscope. -# -# The unit of the nominal dose rate is e-/(angstrom^2*s). -# -# -# -# -# Nominal dose rate. -# -# -# -# -# In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated -# on a helical path about the optical axis. This causes an image rotation whose strength -# is affected by the magnification. -# -# Microscopes may be equipped with compensation methods (implemented in hardware -# or software) that reduce but not necessarily eliminate this rotation. -# -# See `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ for details. -# -# -# -# -# Distance which lies between the principal plane of the lens and the focal point -# along the optical axis. -# -# This concept is related to term `Focal Length`_ of the EMglossary standard. -# -# .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 -# -# -# -# -# Details about an imaging setting used during acquisition to correct perspective -# distortion when imaging a tilted surface or cross section. -# -# This concept is related to term `Tilt Correction`_ of the EMglossary standard. -# -# .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 -# -# -# -# -# Details about a dynamic focus correction used. -# -# This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. -# -# .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 -# -# -# -# -# Details about a workflow used to keep the specimen in focus by automatic means. -# -# This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. -# -# .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_window.yaml b/contributed_definitions/nyaml/NXoptical_window.yaml deleted file mode 100644 index 64a46c580d..0000000000 --- a/contributed_definitions/nyaml/NXoptical_window.yaml +++ /dev/null @@ -1,206 +0,0 @@ -category: base -doc: | - A window of a cryostat, heater, vacuum chamber or a simple glass slide. - - This describes cryostat windows and other possible influences for ellipsometry - measurements. - - 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). - - 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 measurements should be - considered as a separate experiment (with a separate NeXus file), and - the reference data shall be :ref:`linked ` in - ``reference_data_link``. - - 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. -type: group -NXoptical_window(NXaperture): - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If so, describe the window - correction procedure in ``window_correction/procedure``. - window_effects_type: - doc: | - Type of effects due to this window on the measurement. - enumeration: - open_enum: true - items: [interference effects, light absorption, light scattering, other] - window_correction(NXprocess): - doc: | - Group to describe any window correction - if none performed, then omit this - 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_file``. - reference_data_link(NX_NUMBER): - doc: | - :ref:`External link ` to the data field in the NeXus file which describes - the reference data if a reference measurement for window correction - was performed. - - Ideally, the reference measurement was performed on on the same sample, - using the same conditions as for the actual measurement, with - and, if possible, without windows. It should have been conducted as close in time - to the actual measurement as possible. - - Ideally, the link uses the relative path with respect to the actual - NeXus file. - material(NX_CHAR): - doc: | - The material of the window. - enumeration: - open_enum: true - items: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] - material_other(NX_CHAR): - doc: | - If you specified 'other' as material, describe here what it is. - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the window. - orientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19829edf2cc70ea7a87dfe98f1c0ef1785a8923522b0185c237e1971f25acf72 -# -# -# -# -# -# A window of a cryostat, heater, vacuum chamber or a simple glass slide. -# -# This describes cryostat windows and other possible influences for ellipsometry -# measurements. -# -# 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). -# -# 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 measurements should be -# considered as a separate experiment (with a separate NeXus file), and -# the reference data shall be :ref:`linked <Design-Links>` in -# ``reference_data_link``. -# -# 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. -# -# -# -# Was a window correction performed? If so, describe the window -# correction procedure in ``window_correction/procedure``. -# -# -# -# -# Type of effects due to this window on the measurement. -# -# -# -# -# -# -# -# -# -# -# Group to describe any window correction - if none performed, then omit this -# -# -# -# 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_file``. -# -# -# -# -# :ref:`External link <Design-Links>` to the data field in the NeXus file which describes -# the reference data if a reference measurement for window correction -# was performed. -# -# Ideally, the reference measurement was performed on on the same sample, -# using the same conditions as for the actual measurement, with -# and, if possible, without windows. It should have been conducted as close in time -# to the actual measurement as possible. -# -# Ideally, the link uses the relative path with respect to the actual -# NeXus file. -# -# -# -# -# -# The material of the window. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you specified 'other' as material, describe here what it is. -# -# -# -# -# Thickness of the window. -# -# -# -# -# Angle of the window normal (outer) vs. the substrate normal -# (similar to the angle of incidence). -# -# -# diff --git a/contributed_definitions/nyaml/NXphase.yaml b/contributed_definitions/nyaml/NXphase.yaml deleted file mode 100644 index cc2fd666a5..0000000000 --- a/contributed_definitions/nyaml/NXphase.yaml +++ /dev/null @@ -1,122 +0,0 @@ -category: base -doc: | - Base class to describe a (thermodynamic) phase as a component of a material. - - Instances of phases can be crystalline. -type: group -NXphase(NXobject): - phase_id(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model (no sufficiently significant information available). - In other words, the phase_name is n/a aka notIndexed. - - The identifier_phase value should match with the integer suffix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if three phases were used e.g. 0, 1, and 2, three instances of - :ref:`NXphase` named phase0, phase1, and phase2 should be stored - in that HDF5 file. - name(NX_CHAR): - doc: | - Given name as an alias for identifying this phase. - - If the identifier_phase is 0 and one would like to use - the field name, the value should be n/a or notIndexed. - (NXunit_cell): - (NXatom): - - # support for microstructures that are not proposed to the NIAC in this PR - (NXmicrostructure): - doc: | - Instance names should use microstructure as a prefix. - (NXmicrostructure_ipf): - doc: | - Instance names should use ipf as a prefix. - (NXmicrostructure_odf): - doc: | - Instance names should use odf as a prefix. - (NXmicrostructure_pf): - doc: | - Instance names should use pf as a prefix. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c5a14f3c42585361926140d73c3e6ec8ac5b7ad519b624e554623ea2c041849c -# -# -# -# -# -# Base class to describe a (thermodynamic) phase as a component of a material. -# -# Instances of phases can be crystalline. -# -# -# -# Identifier for each phase. -# -# The value 0 is reserved for the unknown phase that represents the -# null-model (no sufficiently significant information available). -# In other words, the phase_name is n/a aka notIndexed. -# -# The identifier_phase value should match with the integer suffix of the -# group name which represents that instance in a NeXus/HDF5 file, i.e. -# if three phases were used e.g. 0, 1, and 2, three instances of -# :ref:`NXphase` named phase0, phase1, and phase2 should be stored -# in that HDF5 file. -# -# -# -# -# Given name as an alias for identifying this phase. -# -# If the identifier_phase is 0 and one would like to use -# the field name, the value should be n/a or notIndexed. -# -# -# -# -# -# -# -# Instance names should use microstructure as a prefix. -# -# -# -# -# Instance names should use ipf as a prefix. -# -# -# -# -# Instance names should use odf as a prefix. -# -# -# -# -# Instance names should use pf as a prefix. -# -# -# diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml deleted file mode 100644 index 56e2d7acae..0000000000 --- a/contributed_definitions/nyaml/NXprogram.yaml +++ /dev/null @@ -1,68 +0,0 @@ -category: base -doc: | - Base class to describe a software tool or library. -type: group -NXprogram(NXobject): - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 611dedddb08da6f30af4a33b7981b959d3dea3346bbd207b12c5f663feacd9ec -# -# -# -# -# -# Base class to describe a software tool or library. -# -# -# -# Given name of the program. Program can be a commercial one a script, -# or a library or a library component. -# -# -# -# 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/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml deleted file mode 100644 index 637e062c56..0000000000 --- a/contributed_definitions/nyaml/NXpump.yaml +++ /dev/null @@ -1,58 +0,0 @@ -category: base -doc: | - Device to reduce an atmosphere (real or simulated) to a controlled pressure. -type: group -NXpump(NXcomponent): - design(NX_CHAR): - 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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 75fd6bed9329fe18baeb5dfb2d5c24e2ac9e3c48d6b874b0e1cb03df60c0c9b4 -# -# -# -# -# -# Device to reduce an atmosphere (real or simulated) to a controlled pressure. -# -# -# -# Principle type of the pump. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml deleted file mode 100644 index e3d8b1bff7..0000000000 --- a/contributed_definitions/nyaml/NXraman.yaml +++ /dev/null @@ -1,398 +0,0 @@ -category: application -doc: | - An application definition for Raman spectroscopy experiments. - - This application definition supports a wide range of Raman spectroscopy experiments. - These may be as simple as acquiring a single Raman spectrum from spontaneous Raman - scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also - includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant - Raman scattering, and multidimensional Raman spectra collected under varying conditions - such as temperature, pressure, or electric field. - - The application definition comprises two main components: - - 1. Structures defined in NXoptical_spectroscopy: - * Instrument configuration and data calibration - * Sensors monitoring sample or beam conditions - - 2. Structures specified and extended in NXraman: - * Description of the experiment type - * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) - * Detailed description of beam properties and their interaction with the sample - * Sample-specific information - - Information on Raman spectroscopy are provided in: - - General - - * Lewis, Ian R.; Edwards, Howell G. M. - Handbook of Raman Spectroscopy - ISBN 0-8247-0557-2 - - Raman scattering selection rules - - * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. - Group Theory - Application to the Physics ofCondensed Matter - ISBN 3540328971 - - Semiconductors - - * Manuel Cardona - Light Scattering in Solids I - eBook ISBN: 978-3-540-37568-5 - DOI: https://doi.org/10.1007/978-3-540-37568-5 - - * Manuel Cardona, Gernot Güntherodt - Light Scattering in Solids II - eBook ISBN: 978-3-540-39075-6 - DOI: https://doi.org/10.1007/3-540-11380-0 - - * See as well other Books from the "Light Scattering in Solids" series: - III: Recent Results - IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects - V: Superlattices and Other Microstructures - VI: Recent Results, Including High-Tc Superconductivity - VII: Crystal-Field and Magnetic Excitations - VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons - IX: Novel Materials and Techniques - - Glasses, Liquids, Gasses, ... - - Review articles: - Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, - Surface-enhanced Raman scattering, Tip-enhanced Raman scattering - * https://doi.org/10.1186/s11671-019-3039-2 -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_scattering_configurations: | - Number of scattering configurations used in the measurement. - It is 1 for only parallel polarization measurement, 2 for parallel and cross - polarization measurement or larger, if i.e. the incident and scattered photon - direction is varied. - -# N_incident_wavelengths: | -# Number of the incident wavelen -# N_incident_beams: | -# to be done.... - -# 04/2024 -# A draft version of a NeXus application definition for Raman spectroscopy. - -# 09/2024 -# TODO (Workshop output): -# - Talk with VIBSO people - possible to synchronize raman_experiment_type with this ontology? -# - Similar to ellipsometry: Separate in-situ from resonant/non-resonant stuff: OR maybe allow multiple selections? -# - Shorten raman_experiment_type by removal of Raman_spectroscopy, but as well fix the Raman Reader in the same run -# - Which for more dataconverters: Output from usually Raman setups to neXus format? -# - Spot size description? -# - Description of defocusing / maybe as well as experiment_type? -# Wishes for NXraman or general next workshop: -# "convert existing data to NeXus" -# "dictionary lookup keywords/fields in existing formats"(?) -# Template for specific experiments (i.e. too complex to get into NeXus/FAIRdata?) - unclear what to do. -# coorporation with VIBSO ontology? -# dataset examples (i.e. NXdata_raman) -type: group -NXraman(NXoptical_spectroscopy): - (NXentry): - definition: - doc: | - An application definition for Raman spectroscopy. - \@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: [NXraman] - title: - exists: recommended - experiment_type: - doc: | - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - enumeration: [Raman spectroscopy] - raman_experiment_type: - doc: | - Specify the type of Raman experiment. - enumeration: - open_enum: true - items: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, tip-enhanced Raman spectroscopy (TERS), surface-enhanced Raman spectroscopy (SERS), surface plasmon polariton enhanced Raman scattering (SPPERS), hyper Raman spectroscopy (HRS), stimulated Raman spectroscopy (SRS), inverse Raman spectroscopy (IRS), coherent anti-Stokes Raman spectroscopy (CARS)] - (NXinstrument): - doc: | - Metadata of the setup, its optical elements and physical properties which - defines the Raman measurement. - scattering_configuration(NX_CHAR): - doc: | - Scattering configuration as defined by the porto notation by three - states, which are orthogonal to each other. Example: z(xx)z for - parallel polarized backscattering configuration. - - See: - https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman - - A(BC)D - - A = The propagation direction of the incident light (k_i) - B = The polarization direction of the incident light (E_i) - C = The polarization direction of the scattered light (E_s) - D = The propagation direction of the scattered light (k_s) - - An orthogonal base is assumed. - Linear polarized light is displayed by e.g. "x","y" or "z" - Unpolarized light is displayed by "." - For non-orthogonal vectors, use the attribute porto_notation_vectors. - \@porto_notation_vectors(NX_NUMBER): - exists: recommended - doc: | - Scattering configuration as defined by the porto notation given by - respective vectors. - - Vectors in the porto notation are defined as for A, B, C, D above. - Linear light polarization is assumed. - dimensions: - rank: 3 - doc: | - 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. - A has to be perpendicular to B and C perpendicular to D. - dim: (4, 3, N_scattering_configurations) - beam_incident(NXbeam): - doc: | - Beam which is incident to the sample. - wavelength(NX_NUMBER): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 14cf7eae6c7b23ce2836ab74734b7a6477b4c668dde01c95c276045f612c3a6f -# -# -# -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Number of scattering configurations used in the measurement. -# It is 1 for only parallel polarization measurement, 2 for parallel and cross -# polarization measurement or larger, if i.e. the incident and scattered photon -# direction is varied. -# -# -# -# -# An application definition for Raman spectroscopy experiments. -# -# This application definition supports a wide range of Raman spectroscopy experiments. -# These may be as simple as acquiring a single Raman spectrum from spontaneous Raman -# scattering, or as complex as Raman imaging with a Raman spectrometer. The scope also -# includes surface- and tip-enhanced Raman techniques, X-ray Raman scattering, resonant -# Raman scattering, and multidimensional Raman spectra collected under varying conditions -# such as temperature, pressure, or electric field. -# -# The application definition comprises two main components: -# -# 1. Structures defined in NXoptical_spectroscopy: -# * Instrument configuration and data calibration -# * Sensors monitoring sample or beam conditions -# -# 2. Structures specified and extended in NXraman: -# * Description of the experiment type -# * Metadata and configuration of the optical setup (e.g., source, monochromator, detector, waveplate, lens) -# * Detailed description of beam properties and their interaction with the sample -# * Sample-specific information -# -# Information on Raman spectroscopy are provided in: -# -# General -# -# * Lewis, Ian R.; Edwards, Howell G. M. -# Handbook of Raman Spectroscopy -# ISBN 0-8247-0557-2 -# -# Raman scattering selection rules -# -# * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. -# Group Theory - Application to the Physics ofCondensed Matter -# ISBN 3540328971 -# -# Semiconductors -# -# * Manuel Cardona -# Light Scattering in Solids I -# eBook ISBN: 978-3-540-37568-5 -# DOI: https://doi.org/10.1007/978-3-540-37568-5 -# -# * Manuel Cardona, Gernot Güntherodt -# Light Scattering in Solids II -# eBook ISBN: 978-3-540-39075-6 -# DOI: https://doi.org/10.1007/3-540-11380-0 -# -# * See as well other Books from the "Light Scattering in Solids" series: -# III: Recent Results -# IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects -# V: Superlattices and Other Microstructures -# VI: Recent Results, Including High-Tc Superconductivity -# VII: Crystal-Field and Magnetic Excitations -# VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons -# IX: Novel Materials and Techniques -# -# Glasses, Liquids, Gasses, ... -# -# Review articles: -# Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, -# Surface-enhanced Raman scattering, Tip-enhanced Raman scattering -# * https://doi.org/10.1186/s11671-019-3039-2 -# -# -# -# -# An application definition for Raman spectroscopy. -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# Specify the type of the optical experiment. -# -# You may specify fundamental characteristics or properties in the experimental sub-type. -# -# -# -# -# -# -# -# Specify the type of Raman experiment. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Metadata of the setup, its optical elements and physical properties which -# defines the Raman measurement. -# -# -# -# Scattering configuration as defined by the porto notation by three -# states, which are orthogonal to each other. Example: z(xx)z for -# parallel polarized backscattering configuration. -# -# See: -# https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman -# -# A(BC)D -# -# A = The propagation direction of the incident light (k_i) -# B = The polarization direction of the incident light (E_i) -# C = The polarization direction of the scattered light (E_s) -# D = The propagation direction of the scattered light (k_s) -# -# An orthogonal base is assumed. -# Linear polarized light is displayed by e.g. "x","y" or "z" -# Unpolarized light is displayed by "." -# For non-orthogonal vectors, use the attribute porto_notation_vectors. -# -# -# -# Scattering configuration as defined by the porto notation given by -# respective vectors. -# -# Vectors in the porto notation are defined as for A, B, C, D above. -# Linear light polarization is assumed. -# -# -# -# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. -# A has to be perpendicular to B and C perpendicular to D. -# -# -# -# -# -# -# -# -# -# Beam which is incident to the sample. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index 4c79cb0b68..0000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,62 +0,0 @@ -category: base -doc: | - Base class to report on a region-of-interest of material analyzed or simulated. - - Do not confuse this base class with :ref:`NXregion`. -type: group -NXroi(NXobject): - - # generic base classes - (NXprocess): - (NXdata): - (NXimage): - (NXspectrum): - - # domain-specific customizations - (NXem_img): - (NXem_ebsd): - (NXem_eds): - (NXem_eels): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0d5c54aa964fe3be7058ec1295d958c2659d243c90a95d232f8bf4a8e26bad5d -# -# -# -# -# -# Base class to report on a region-of-interest of material analyzed or simulated. -# -# Do not confuse this base class with :ref:`NXregion`. -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXrotations.yaml b/contributed_definitions/nyaml/NXrotations.yaml deleted file mode 100644 index d9e2bbfbd8..0000000000 --- a/contributed_definitions/nyaml/NXrotations.yaml +++ /dev/null @@ -1,439 +0,0 @@ -category: base - -# can this class take the name from the deprecated NXorientation class? -doc: | - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge `_ - * `T. B. Britton et al. `_ - * `D. Rowenhorst et al. `_ - * `A. Morawiec `_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet `_ - - The concepts of mis- and disorientation are relevant when analyzing the - crystallography of interfaces. -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 value tuples. - n_phases: | - How many phases with usually different crystal and symmetry are distinguished. -type: group -NXrotations(NXobject): - reference_frame(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` which contextualizes - how the here reported parameterized quantities can be interpreted. - crystal_symmetry(NX_CHAR): - doc: | - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided, point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field needs to encode two strings: - The first string is for phase A. The second string is for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - dimensions: - rank: 1 - dim: (n_phases,) - sample_symmetry(NX_CHAR): - doc: | - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided, point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, have become obsolete thanks - to improvements in methods, software, and available computing power. - - Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. - dimensions: - rank: 1 - dim: (n_phases,) - rotation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. - dimensions: - rank: 2 - dim: (c, 4) - rotation_euler(NX_NUMBER): - unit: NX_ANGLE - doc: | - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many possible - Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: (c, 3) - - # rotation_rodrigues(NX_NUMBER): - # rotation_homochoric(NX_NUMBER): - # rotation_axis_angle(NX_NUMBER): - - # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry - is_antipodal(NX_BOOLEAN): - doc: | - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - dimensions: - rank: 1 - dim: (c,) - orientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. - dimensions: - rank: 2 - dim: (c, 4) - orientation_euler(NX_NUMBER): - unit: NX_ANGLE - doc: | - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the rotation - conventions behind reference_frame to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: (c, 3) - - # orientation_rodrigues(NX_NUMBER): - # orientation_homochoric(NX_NUMBER): - # orientation_axis_angle(NX_NUMBER): - misorientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - The misorientation should not be confused with the disorientation, - as for the latter the angular argument is expected to be the minimal - obeying symmetries. - dimensions: - rank: 2 - dim: (c, 4) - misorientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - dimensions: - rank: 1 - dim: (c,) - misorientation_axis(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - dimensions: - rank: 2 - dim: (c, 3) - - # disorientation, misorientation with smallest angular argument inside - # fundamental zone of SO3 for given crystal and sample symmetry - disorientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of disorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent disorientations - as defined by crystal_symmetry and sample_symmetry. - dimensions: - rank: 2 - dim: (c, 4) - disorientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Disorientations angular argument (should not be signed, see - `D. Rowenhorst et al. `_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - dimensions: - rank: 1 - dim: (c,) - disorientation_axis(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Disorientations axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. - dimensions: - rank: 2 - dim: (c, 3) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 239aa437e4fe8b7fac66e7536590b07dbedff1e73a6f5361bff263fae970c716 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of value tuples. -# -# -# -# -# How many phases with usually different crystal and symmetry are distinguished. -# -# -# -# -# -# Base class to detail a set of rotations, orientations, and disorientations. -# -# For getting a more detailed insight into the discussion of the -# parameterized description of orientations in materials science see: -# -# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ -# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ -# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ -# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ -# -# Once orientations are defined, one can continue to characterize the -# misorientation and specifically the disorientation. The misorientation describes -# the rotation that is required to register the lattices of two oriented objects -# (like crystal lattice) into a crystallographic equivalent orientation: -# -# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ -# -# The concepts of mis- and disorientation are relevant when analyzing the -# crystallography of interfaces. -# -# -# -# Reference to an instance of :ref:`NXcoordinate_system` which contextualizes -# how the here reported parameterized quantities can be interpreted. -# -# -# -# -# Point group which defines the symmetry of the crystal. -# -# This has to be at least a single string. If crystal_symmetry is not -# provided, point group 1 is assumed. -# -# In the case that misorientation or disorientation fields are used -# and the two crystal sets resolve for phases with a different -# crystal symmetry, this field needs to encode two strings: -# The first string is for phase A. The second string is for phase B. -# An example of this most complex case is the description of the -# disorientation between crystals adjoining a hetero-phase boundary. -# -# -# -# -# -# -# -# Point group which defines an assumed symmetry imprinted upon processing -# the material/sample which could give rise to or may justify to use a -# simplified description of rotations, orientations, misorientations, -# and disorientations via numerical procedures that are known as -# symmetrization. -# -# If sample_symmetry is not provided, point group 1 is assumed. -# -# The traditionally used symmetrization operations within the texture -# community in Materials Science, though, have become obsolete thanks -# to improvements in methods, software, and available computing power. -# -# Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic). -# -# In practice one often faces situations where indeed these assumed -# symmetries are anyway not fully observed, and thus an accepting of -# eventual inaccuracies just for the sake of reporting a simplified -# symmetrized description should be avoided. -# -# -# -# -# -# -# -# The set of rotations expressed in quaternion parameterization considering -# crystal_symmetry and sample_symmetry. Rotations which should be -# interpreted as antipodal are not marked as such. -# -# -# -# -# -# -# -# -# The set of rotations expressed in Euler angle parameterization considering -# the same applied symmetries as detailed for the field rotation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the rotation -# conventions behind reference_frame to resolve which of the many possible -# Euler-angle conventions (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# -# -# True for all those value tuples which have assumed antipodal symmetry. -# False for all others. -# -# -# -# -# -# -# -# The set of orientations expressed in quaternion parameterization and -# obeying symmetry for equivalent cases as detailed in crystal_symmetry -# and sample_symmetry. The supplementary field is_antipodal can be used -# to mark orientations with the antipodal property. -# -# -# -# -# -# -# -# -# The set of orientations expressed in Euler angle parameterization following -# the same assumptions like for orientation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the rotation -# conventions behind reference_frame to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# -# The set of misorientations expressed in quaternion parameterization -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# The misorientation should not be confused with the disorientation, -# as for the latter the angular argument is expected to be the minimal -# obeying symmetries. -# -# -# -# -# -# -# -# -# Misorientation angular argument (eventually signed) following the same -# symmetry assumptions as expressed for the field misorientation_quaternion. -# -# -# -# -# -# -# -# Misorientation axis (normalized) and signed following the same -# symmetry assumptions as expressed for the field misorientation_angle. -# -# -# -# -# -# -# -# -# -# The set of disorientations expressed in quaternion parameterization -# obeying symmetry operations for equivalent disorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# -# -# -# -# -# -# -# Disorientations angular argument (should not be signed, see -# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) -# following the same symmetry assumptions as expressed for the field -# disorientation_quaternion. -# -# -# -# -# -# -# -# Disorientations axis (normalized) following the same symmetry assumptions -# as expressed for the field disorientation_angle. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml deleted file mode 100644 index af795aae81..0000000000 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ /dev/null @@ -1,123 +0,0 @@ -category: base -doc: | - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. -symbols: - n_comp: | - number of components -type: group -NXsample_component_set(NXobject): - \@components: - doc: | - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: (n_comp,) - volume_fraction(NX_FLOAT): - unit: NX_ANY - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: (n_comp,) - scattering_length_density(NX_FLOAT): - unit: NX_ANY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: (n_comp,) - (NXsample_component): - doc: | - Each component set can contain multiple components. - (NXsample_component_set): - doc: | - For description of a sub-component set. Can contain multiple components itself. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 26138aec233d84eded13a838e664ab7e813632357cc815020fff224828879a20 -# -# -# -# -# -# -# -# number of components -# -# -# -# -# Set of sample components and their configuration. -# -# The idea here is to have a united place for all materials descriptors that are not -# part of the individual sample components, but rather their configuration. -# -# -# -# Array of strings referring to the names of the NXsample_components. -# The order of these components serves as an index (starting at 1). -# -# -# -# -# Concentration of each component -# -# -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# -# Each component set can contain multiple components. -# -# -# -# -# For description of a sub-component set. Can contain multiple components itself. -# -# -# diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml deleted file mode 100644 index 02523c3fd6..0000000000 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ /dev/null @@ -1,141 +0,0 @@ -category: base -doc: | - Scan box and coils which deflect a beam of charged particles in a controlled manner. - - The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, - which is not necessarily the same program as the one controlling other parts of the instrument. - - The scanbox directs the probe of charged particles (electrons, ions) - to controlled locations according to a scan scheme and plan. -type: group -NXscanbox_em(NXcomponent): - - # user perspective - scan_schema(NX_CHAR): - doc: | - Name of the typically tech-partner-specific term that specifies an - automated protocol which details how the components of the scan_box - and the instrument work together to achieve a controlled - scanning of the beam (over the sample surface). - - Oftentimes users do not need to or are not able to disentangle the intricate - details of the spatiotemporal dynamics of their instrument. Instead, often - they rely on the assumption that the instrument and its controlling programs - work as expected. The field scan_schema can be used to add some constraints - on how the beam was scanned over the surface. - - # descriptors relevant from economic usage (costs) of the instrument and dose management perspective (radiation damage) - dwell_time(NX_NUMBER): - unit: NX_TIME - doc: - - | - Time period during which the beam remains at one position. - - | - xref: - spec: EMglossary - term: Dwell Time - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - flyback_time(NX_NUMBER): - unit: NX_TIME - doc: - - | - Time period during which the beam moves from the final position of one scan - line to the starting position of the subsequent scan line. - - | - xref: - spec: EMglossary - term: Flyback Time - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 - - # technical design perspective - (NXdeflector): - doc: | - Details about components which realize the deflection technically. - - This concept should be used for all those components that implement - the scanning of the beam, while components like beam blankers etc. should - use rather the NXdeflector concept of the NXebeam_column base class. - (NXcircuit): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 03e9a9a11e3ca9ebe548efc0e0d063132c488554d023069c1c2f446b6639a644 -# -# -# -# -# -# Scan box and coils which deflect a beam of charged particles in a controlled manner. -# -# The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, -# which is not necessarily the same program as the one controlling other parts of the instrument. -# -# The scanbox directs the probe of charged particles (electrons, ions) -# to controlled locations according to a scan scheme and plan. -# -# -# -# -# Name of the typically tech-partner-specific term that specifies an -# automated protocol which details how the components of the scan_box -# and the instrument work together to achieve a controlled -# scanning of the beam (over the sample surface). -# -# Oftentimes users do not need to or are not able to disentangle the intricate -# details of the spatiotemporal dynamics of their instrument. Instead, often -# they rely on the assumption that the instrument and its controlling programs -# work as expected. The field scan_schema can be used to add some constraints -# on how the beam was scanned over the surface. -# -# -# -# -# -# Time period during which the beam remains at one position. -# -# This concept is related to term `Dwell Time`_ of the EMglossary standard. -# -# .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 -# -# -# -# -# Time period during which the beam moves from the final position of one scan -# line to the starting position of the subsequent scan line. -# -# This concept is related to term `Flyback Time`_ of the EMglossary standard. -# -# .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 -# -# -# -# -# -# Details about components which realize the deflection technically. -# -# This concept should be used for all those components that implement -# the scanning of the beam, while components like beam blankers etc. should -# use rather the NXdeflector concept of the NXebeam_column base class. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspectrum.yaml b/contributed_definitions/nyaml/NXspectrum.yaml deleted file mode 100644 index 78515456a4..0000000000 --- a/contributed_definitions/nyaml/NXspectrum.yaml +++ /dev/null @@ -1,934 +0,0 @@ -category: base -doc: | - Base class container for reporting a set of spectra. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Use stack for all other tilings. - -# set of frequently made specializations of NXdata instances for spectra -symbols: - n_spc: | - Number of spectra in the stack, for stacks the slowest dimension. - n_k: | - Number of image points along the slower dimension (k equivalent to z). - n_j: | - Number of image points along the slow dimension (j equivalent to y). - n_i: | - Number of image points along the fast dimension (i equivalent to x). - n_energy: | - Number of energy bins (always the fastest dimension). -type: group -NXspectrum(NXobject): - (NXprocess): - doc: | - Details how spectra were processed from the detector readings. - input(NXnote): - doc: | - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` - instances in this :ref:`NXspectrum` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *context* therein adds context. - context(NX_CHAR): - doc: | - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - mode(NX_CHAR): - doc: | - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXspectrum` instance. - detector_identifier(NX_CHAR): - doc: | - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - (NXprogram): - spectrum_0d(NXdata): - doc: | - One spectrum for a point of a 0d ROI. Also known as spot measurement. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Counts - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - spectrum_1d(NXdata): - doc: | - One spectrum for each point of a 1d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 2 - dim: (n_i, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - spectrum_2d(NXdata): - doc: | - One spectrum for each scan point of 2d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 3 - dim: (n_j, n_i, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - spectrum_3d(NXdata): - doc: | - One spectrum for point of a 3d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 4 - dim: (n_k, n_j, n_i, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slower dimension - dimensions: - rank: 1 - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slower dimension - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - stack_0d(NXdata): - doc: | - Multiple instances of spectrum_0d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 2 - dim: (n_spc, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_spectrum(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Spectrum identifier - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - stack_2d(NXdata): - doc: | - Multiple instances of spectrum_2d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 4 - dim: (n_spc, n_j, n_i, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_spectrum(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Spectrum identifier - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - stack_3d(NXdata): - doc: | - Multiple instances of spectrum_3d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 5 - dim: (n_spc, n_k, n_j, n_i, n_energy) - \@long_name(NX_CHAR): - doc: | - Counts - indices_group(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Group identifier - indices_spectrum(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: (n_spc,) - \@long_name(NX_CHAR): - doc: | - Spectrum identifier - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slower dimension - dimensions: - rank: 1 - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slower dimension - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension - dimensions: - rank: 1 - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the slow dimension - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension - dimensions: - rank: 1 - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: (n_energy,) - \@long_name(NX_CHAR): - doc: | - Energy - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 68227c894efa4e970e8826facd84d2676cd89a1a8de369b7af5df2856417c3e6 -# -# -# -# -# -# -# -# -# Number of spectra in the stack, for stacks the slowest dimension. -# -# -# -# -# Number of image points along the slower dimension (k equivalent to z). -# -# -# -# -# Number of image points along the slow dimension (j equivalent to y). -# -# -# -# -# Number of image points along the fast dimension (i equivalent to x). -# -# -# -# -# Number of energy bins (always the fastest dimension). -# -# -# -# -# Base class container for reporting a set of spectra. -# -# The mostly commonly used scanning methods are supported. That is one-, -# two-, three-dimensional ROIs discretized using regular Euclidean tilings. -# -# Use stack for all other tilings. -# -# -# -# Details how spectra were processed from the detector readings. -# -# -# -# Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` -# instances in this :ref:`NXspectrum` were loaded during parsing. -# -# Possibility to document from which specific other serialized resource as the source -# pieces of information were processed when using NeXus as a semantic file format -# to serialize that information differently. -# -# The group in combination with an added field *context* therein adds context. -# -# -# -# Reference to a location inside the artifact that points to the specific group of values -# that were processed if the artifacts contains several groups of values and thus -# further resolving of ambiguities is required. -# -# -# -# -# -# Imaging (data collection) mode of the instrument during acquisition -# of the data in this :ref:`NXspectrum` instance. -# -# -# -# -# Link or name of an :ref:`NXdetector` instance with which the data were -# collected. -# -# -# -# -# -# -# One spectrum for a point of a 0d ROI. Also known as spot measurement. -# -# -# -# Counts -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for each point of a 1d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for each scan point of 2d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for point of a 3d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the slower dimension -# -# -# -# -# -# -# Point coordinate along the slower dimension -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Multiple instances of spectrum_0d. -# -# -# -# Counts -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Multiple instances of spectrum_2d. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Multiple instances of spectrum_3d. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Point coordinate along the slower dimension -# -# -# -# -# -# -# Point coordinate along the slower dimension -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# -# Point coordinate along the slow dimension -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml deleted file mode 100644 index f8a698af91..0000000000 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ /dev/null @@ -1,267 +0,0 @@ -category: base -doc: | - Base class to describe structural aspects of an arrangement of - atoms or ions including a crystallographic unit cell. - - Following recommendations of `CIF `_ and `International Tables of Crystallography `_. -symbols: - d: | - Dimensionality of the lattice. -type: group -NXunit_cell(NXobject): - reference_frame(NX_CHAR): - doc: | - Path to a reference frame in which the unit cell is defined - to resolve ambiguity in cases when e.g. a different reference frame - than the NeXus default reference frame (McStas) was chosen. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the structure. - enumeration: [1, 2, 3] - a_b_c(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometry of the unit cell quantified via parameters a, b, and c. - dimensions: - rank: 1 - dim: (d,) - a(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometry of the unit cell quantified individually via parameter a. - b(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometry of the unit cell quantified individually via parameter b. - c(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometry of the unit cell quantified individually via parameter c. - alpha_beta_gamma(NX_NUMBER): - unit: NX_ANGLE - doc: | - Geometry of the unit cell quantified via parameters alpha, beta, and gamma. - dimensions: - rank: 1 - dim: (d,) - alpha(NX_NUMBER): - unit: NX_ANGLE - doc: | - Geometry of the unit cell quantified individually via parameter alpha. - beta(NX_NUMBER): - unit: NX_ANGLE - doc: | - Geometry of the unit cell quantified individually via parameter beta. - gamma(NX_NUMBER): - unit: NX_ANGLE - doc: | - Geometry of the unit cell quantified individually via parameter gamma. - crystal_system(NX_CHAR): - doc: | - Crystal system. - - For a crystal system in 2D space monoclinic is an exact synonym for oblique. - For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. - For a crystal system in 2D space tetragonal is an exact synonym for square. - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography notation. - - # add enumeration of all possible ones here to create a closed enum? - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography notation. - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography notation. - 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. - area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the unit cell if dimensionality is 2. - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of the unit cell if dimensionality is 3. - (NXatom): - (NXion): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fdd8867d5685846d9941acea8918de7e7d913df6cd70d4718d9d3931674bbd45 -# -# -# -# -# -# -# -# Dimensionality of the lattice. -# -# -# -# -# Base class to describe structural aspects of an arrangement of -# atoms or ions including a crystallographic unit cell. -# -# Following recommendations of `CIF <https://www.iucr.org/resources/cif/spec/version1.1>`_ and `International Tables of Crystallography <https://it.iucr.org/>`_. -# -# -# -# Path to a reference frame in which the unit cell is defined -# to resolve ambiguity in cases when e.g. a different reference frame -# than the NeXus default reference frame (McStas) was chosen. -# -# -# -# -# Dimensionality of the structure. -# -# -# -# -# -# -# -# -# -# Geometry of the unit cell quantified via parameters a, b, and c. -# -# -# -# -# -# -# -# Geometry of the unit cell quantified individually via parameter a. -# -# -# -# -# Geometry of the unit cell quantified individually via parameter b. -# -# -# -# -# Geometry of the unit cell quantified individually via parameter c. -# -# -# -# -# Geometry of the unit cell quantified via parameters alpha, beta, and gamma. -# -# -# -# -# -# -# -# Geometry of the unit cell quantified individually via parameter alpha. -# -# -# -# -# Geometry of the unit cell quantified individually via parameter beta. -# -# -# -# -# Geometry of the unit cell quantified individually via parameter gamma. -# -# -# -# -# Crystal system. -# -# For a crystal system in 2D space monoclinic is an exact synonym for oblique. -# For a crystal system in 2D space orthorhombic is an exact synonym for rectangular. -# For a crystal system in 2D space tetragonal is an exact synonym for square. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Laue group using International Table of Crystallography notation. -# -# -# -# -# -# Point group using International Table of Crystallography notation. -# -# -# -# -# Space group from the International Table of Crystallography notation. -# -# -# -# -# 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. -# -# -# -# -# Area of the unit cell if dimensionality is 2. -# -# -# -# -# Volume of the unit cell if dimensionality is 3. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml deleted file mode 100644 index 3fd050ed00..0000000000 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ /dev/null @@ -1,276 +0,0 @@ -category: base -doc: | - A waveplate or retarder. -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. -type: group -NXwaveplate(NXcomponent): - type: - doc: | - Type of waveplate (e.g. achromatic or zero-order). - enumeration: - open_enum: true - items: [zero-order, achromatic, multiple-order, dual-wavelength] - retardance: - doc: | - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4)). - enumeration: [full-wave, half-wave, quarter-wave] - 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). In this case, also use type="achromatic". - dimensions: - rank: 1 - dim: (N_wavelengths,) - retardance_distribution(NXdata): - doc: | - Wavelength resolved retardance of the waveplate. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Diameter of the waveplate (if the waveplate is circular). - clear_aperture(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of - length/height for square geometry). - - # Would it be better to provide the clear aperture as length? - substrate(NXsample): - doc: | - Describe the material of the substrate of the waveplate 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 waveplate. If the device has a - coating it should be described in coating/coating_material. - substrate_thickness(NX_NUMBER): - unit: NX_LENGTH - doc: | - Thickness of the waveplate substrate. - index_of_refraction_substrate(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the waveplate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: (2, N_spectrum) - coating(NXsample): - doc: | - Is the waveplate 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): - unit: NX_LENGTH - doc: | - Thickness of the coating. - 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: (2,) - index_of_refraction_coating(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: (2, N_spectrum) - reflectance(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Average reflectance of the waveplate in percentage. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fa0e24f757f671085313b91e45bbdd4b7ae6ecf448e4f5166c33a121a9fc9288 -# -# -# -# -# -# -# -# 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 or zero-order). -# -# -# -# -# -# -# -# -# -# -# Specify the retardance of the waveplate (e.g. full-wave, half-wave -# (lambda/2), quarter-wave (lambda/4)). -# -# -# -# -# -# -# -# -# -# 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). In this case, also use type="achromatic". -# -# -# -# -# -# -# -# Wavelength resolved retardance of the waveplate. -# -# -# -# -# Diameter of the waveplate (if the waveplate is circular). -# -# -# -# -# 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 waveplate in -# substrate/substrate_material and provide its index of refraction in -# substrate/index_of_refraction_substrate, if known. -# -# -# -# Specify the material of the waveplate. If the device has a -# coating it should be described in coating/coating_material. -# -# -# -# -# Thickness of the waveplate substrate. -# -# -# -# -# Complex index of refraction of the waveplate substrate. Specify at -# given wavelength (or energy, wavenumber etc.) values. -# -# -# -# -# -# -# -# -# -# Is the waveplate 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. -# -# -# \ No newline at end of file From 03d9fbba826a5c015ffb3b21ff568dbebc79600f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 15 Jul 2025 22:43:35 +0200 Subject: [PATCH 42/57] Refactoring of deprecated NXion to NXatom --- .../NXapm_compositionspace_results.nxdl.xml | 2 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 4 ++-- .../NXapm_paraprobe_ranger_results.nxdl.xml | 4 ++-- .../NXapm_paraprobe_transcoder_results.nxdl.xml | 4 ++-- .../nyaml/NXapm_compositionspace_results.yaml | 6 +++--- .../nyaml/NXapm_paraprobe_nanochem_results.yaml | 10 +++++----- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 10 +++++----- .../nyaml/NXapm_paraprobe_transcoder_results.yaml | 10 +++++----- 8 files changed, 25 insertions(+), 25 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 8c689b7150..e1bcb394f8 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -200,7 +200,7 @@ - + Chemical symbol of the element from the periodic table. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 66bdd7252c..c1c1b20621 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -908,7 +908,7 @@ MK::namely k != i each OBB has eight vertices--> - + @@ -1191,7 +1191,7 @@ MK::namely k != i each OBB has eight vertices--> - Hashvalue as defined in :ref:`NXion`. + Hashvalue as defined in :ref:`NXatom`. diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index e0194012e3..3b7e7b2a0f 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -61,7 +61,7 @@ - + @@ -75,7 +75,7 @@ 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 those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. + a (molecular) ion is assumed composed according to the NXatom instances. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 7843ba2920..806d27f650 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -22,7 +22,7 @@ # For further information, see http://www.nexusformat.org --> +i be careful n_comb can vary for every instance of (NXatom) !--> @@ -149,7 +149,7 @@ config--> Details about how peaks are interpreted as ion types or not. - + diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 0ffc8f37d0..8e65f89089 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -142,7 +142,7 @@ NXapm_compositionspace_results(NXobject): for the occupancy of each voxel with atoms. dimensions: dim: (n_voxels,) - (NXion): + (NXatom): exists: ['min', '1', 'max', 'unbounded'] name(NX_CHAR): doc: | @@ -309,7 +309,7 @@ NXapm_compositionspace_results(NXobject): dim: (n_voxels,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b58f5eaadbf095897f66b55f2637fa152aa25fa11bc1b71ae808b4065494548d +# 735b187b1429dbf082283a98acd44503f05d26cfbd5ccad861338be7411fa7ac # # # # @@ -2265,7 +2265,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Hashvalue as defined in :ref:`NXion`. +# Hashvalue as defined in :ref:`NXatom`. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 143839cf6f..cff4a993cb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -32,7 +32,7 @@ NXapm_paraprobe_ranger_results(NXobject): mask(NX_UINT): # results - (NXion): + (NXatom): exists: ['min', '1', 'max', '256'] nuclide_hash(NX_UINT): nuclide_list(NX_UINT): @@ -49,7 +49,7 @@ NXapm_paraprobe_ranger_results(NXobject): 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 those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. + a (molecular) ion is assumed composed according to the NXatom instances. dimensions: rank: 1 dim: (n_ions,) @@ -99,7 +99,7 @@ NXapm_paraprobe_ranger_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ebf077a701c882987717f3ef00b14b8ce16aba802a82a88d84b3ae99060f6d7 +# 1189e257b7cfcd00a8d774dccc8676893f29cd0971eb8d6f848158dd34ea0197 # # # -# +# # # # @@ -177,7 +177,7 @@ NXapm_paraprobe_ranger_results(NXobject): # 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 those elements are considered of which -# a (molecular) ion is assumed composed according to the NXion instances. +# a (molecular) ion is assumed composed according to the NXatom instances. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index c7b52ef399..98dab27573 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -36,7 +36,7 @@ symbols: n_variable: | Number of entries -# i be careful n_comb can vary for every instance of (NXion) ! +# i be careful n_comb can vary for every instance of (NXatom) ! type: group NXapm_paraprobe_transcoder_results(NXobject): (NXentry): @@ -103,7 +103,7 @@ NXapm_paraprobe_transcoder_results(NXobject): peak_identification(NXprocess): doc: | Details about how peaks are interpreted as ion types or not. - (NXion): + (NXatom): exists: ['min', '1', 'max', '256'] nuclide_hash(NX_UINT): nuclide_list(NX_UINT): @@ -162,7 +162,7 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 856a4a568eaaab5878232d533f49589a6d52facb8deb2470d14e3d96f3bf269c +# a1a2458e64d3132b794bf519c586b6a84beab70edc3738537d0e8661bb083f8e # # # # +# i be careful n_comb can vary for every instance of (NXatom) !--> # # # @@ -314,7 +314,7 @@ NXapm_paraprobe_transcoder_results(NXobject): # # Details about how peaks are interpreted as ion types or not. # -# +# # # # From dc005f5ce3fb87e89b5154970b27bfb259119e60 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 15 Jul 2025 22:53:11 +0200 Subject: [PATCH 43/57] Fixing math env error for rendering in rst for NXatom --- base_classes/NXatom.nxdl.xml | 2 +- base_classes/nyaml/NXatom.yaml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/base_classes/NXatom.nxdl.xml b/base_classes/NXatom.nxdl.xml index e8f2a55598..7f722b3727 100644 --- a/base_classes/NXatom.nxdl.xml +++ b/base_classes/NXatom.nxdl.xml @@ -163,7 +163,7 @@ Individual hash values :math:`H` `encode <https://doi.org/10.1017/S1431927621012241>`_ for each nuclide or element the number of protons :math:`Z` and a constant :math:`c` - via the following hashing rule :math:`H = Z + c \cdot 256` . :math:`Z and c` must be 8-bit unsigned integers. + via the following hashing rule :math:`H = Z + c \cdot 256`. :math:`Z` and :math:`c` must be 8-bit unsigned integers. The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. diff --git a/base_classes/nyaml/NXatom.yaml b/base_classes/nyaml/NXatom.yaml index ce72b8adf8..97f759fe1c 100644 --- a/base_classes/nyaml/NXatom.yaml +++ b/base_classes/nyaml/NXatom.yaml @@ -110,7 +110,7 @@ NXatom(NXobject): Individual hash values :math:`H` `encode `_ for each nuclide or element the number of protons :math:`Z` and a constant :math:`c` - via the following hashing rule :math:`H = Z + c \cdot 256` . :math:`Z and c` must be 8-bit unsigned integers. + via the following hashing rule :math:`H = Z + c \cdot 256`. :math:`Z` and :math:`c` must be 8-bit unsigned integers. The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. @@ -158,7 +158,7 @@ NXatom(NXobject): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1b11080cf5aae3fd44f2010cbf2e7818a41f9b452dbfcd92396c4ab4fa94ba3d +# e57066e1ede555906f8123210b0f0c42ec8669a0a94d7675d01b902a5b67c321 # # # - + @@ -1489,7 +1519,7 @@ basically optional use of NXaberration therein at least some value required--> - + @@ -1510,12 +1540,12 @@ basically optional use of NXaberration therein at least some value required--> - + - + @@ -1585,7 +1615,7 @@ basically optional use of NXaberration therein at least some value required--> - + diff --git a/applications/nyaml/NXapm.yaml b/applications/nyaml/NXapm.yaml index 5372f6bf3f..4645018df1 100644 --- a/applications/nyaml/NXapm.yaml +++ b/applications/nyaml/NXapm.yaml @@ -667,7 +667,7 @@ NXapm(NXobject): reflectron(NXcomponent): exists: optional applied(NX_BOOLEAN): - local_electrode(NXlens_em): + local_electrode(NXelectromagnetic_lens): exists: recommended name(NX_CHAR): fabrication(NXfabrication): @@ -771,7 +771,7 @@ NXapm(NXobject): reflectron(NXcomponent): exists: recommended voltage(NX_FLOAT): - local_electrode(NXlens_em): + local_electrode(NXelectromagnetic_lens): exists: recommended voltage(NX_FLOAT): pulser(NXcomponent): @@ -1531,7 +1531,7 @@ NXapm(NXobject): dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7dc62384d7e42be7e77a61245f222c63c94a65b9e296fd90898b192b722152d0 +# 1a42cc4c10e3294b81e4b0d78ab51ccd93d9f6d87ee04eff5a7d7436db9e352e # # # A collection with one or more computing nodes each with own resources. @@ -145,6 +141,4 @@ complicated models should be captured.--> ID is an increasing unsigned integer starting at 1. - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml index 2901558992..d27ac26085 100644 --- a/base_classes/NXebeam_column.nxdl.xml +++ b/base_classes/NXebeam_column.nxdl.xml @@ -123,7 +123,7 @@ - + @@ -235,5 +235,5 @@ - + diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXelectromagnetic_lens.nxdl.xml similarity index 90% rename from base_classes/NXlens_em.nxdl.xml rename to base_classes/NXelectromagnetic_lens.nxdl.xml index d4c1e2055b..3cf9ed46d3 100644 --- a/base_classes/NXlens_em.nxdl.xml +++ b/base_classes/NXelectromagnetic_lens.nxdl.xml @@ -21,18 +21,13 @@ # # For further information, see http://www.nexusformat.org --> - - - + Base class for an electro-magnetic lens or a compound lens. For :ref:`NXtransformations` the origin of the coordinate system is placed - in the center of the lens (its polepiece, pinhole, or another - point of reference). The origin should be specified in the :ref:`NXtransformations`. + in the center of the lens its polepiece, pinhole, or another point of reference. + The origin should be specified in the :ref:`NXtransformations`. For details of electro-magnetic lenses in the literature see e.g. diff --git a/base_classes/NXelectronanalyzer.nxdl.xml b/base_classes/NXelectronanalyzer.nxdl.xml index 6d0d4b6f15..1d990fec5e 100644 --- a/base_classes/NXelectronanalyzer.nxdl.xml +++ b/base_classes/NXelectronanalyzer.nxdl.xml @@ -272,7 +272,7 @@ Deflectors outside the main optics ensembles described by the subclasses - + Individual lenses outside the main optics ensembles described by the subclasses diff --git a/base_classes/NXinteraction_volume_em.nxdl.xml b/base_classes/NXem_interaction_volume.nxdl.xml similarity index 97% rename from base_classes/NXinteraction_volume_em.nxdl.xml rename to base_classes/NXem_interaction_volume.nxdl.xml index f7ba212c79..c7f6fe27ab 100644 --- a/base_classes/NXinteraction_volume_em.nxdl.xml +++ b/base_classes/NXem_interaction_volume.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class to describe the volume of interaction for particle-matter interaction. diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXem_optical_system.nxdl.xml similarity index 97% rename from base_classes/NXoptical_system_em.nxdl.xml rename to base_classes/NXem_optical_system.nxdl.xml index f40401df37..73c90f0057 100644 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ b/base_classes/NXem_optical_system.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class for qualifying an electron optical system. @@ -113,7 +113,7 @@ rank: 2--> - In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated + In the process of passing through an :ref:`NXelectromagnetic_lens` electrons are typically accelerated on a helical path about the optical axis. This causes an image rotation whose strength is affected by the magnification. diff --git a/base_classes/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml index 1381cb6adc..0e42021f72 100644 --- a/base_classes/NXenergydispersion.nxdl.xml +++ b/base_classes/NXenergydispersion.nxdl.xml @@ -168,7 +168,7 @@ Deflectors in the energy dispersive section - + Individual lenses in the energy dispersive section diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml index 9d5576e3f1..e12b098dd9 100644 --- a/base_classes/NXibeam_column.nxdl.xml +++ b/base_classes/NXibeam_column.nxdl.xml @@ -128,7 +128,7 @@ NEW ISSUE: (at which location?).--> - + @@ -149,7 +149,7 @@ NEW ISSUE: (at which location?).--> - + diff --git a/base_classes/NXimage.nxdl.xml b/base_classes/NXimage.nxdl.xml index d425fd0019..d296a7b27a 100644 --- a/base_classes/NXimage.nxdl.xml +++ b/base_classes/NXimage.nxdl.xml @@ -36,7 +36,7 @@ - Number of image points along the slow dimension. + Number of image points along the slow dimension (k equivalent to z). @@ -61,9 +61,10 @@ pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually more appropriate when working with such tilings. + image point is eventually more appropriate when working with such tilings. - Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). + Therefore, all docstrings in this base class refer to points. Points are considered + exact synonyms for pixel and voxel, which are terms used for regular tilings. Point coordinates identify the location of the barycenter. @@ -92,7 +93,7 @@ Classically, images depict objects in real space. Such usage of NXimage essentially is equivalent to storing pictures. For this purpose the image_1d, image_2d, or image_3d NXdata instances respectively - should be used with all their axes axis_i, axis_j, axis_k constrained to NeXus Unit Category NX_LENGTH. + should be used such that all their axes axis_i, axis_j, axis_k are constrained to NeXus Unit Category NX_LENGTH. Imaging modes in electron microscopy are typically more versatile, specifically for use cases in scanning transmission electron microscopy, so-called 4DSTEM. In this case, one two-dimensional diff --git a/base_classes/NXinstrument_apm.nxdl.xml b/base_classes/NXinstrument_apm.nxdl.xml index cd4bd92a51..10b76c84e7 100644 --- a/base_classes/NXinstrument_apm.nxdl.xml +++ b/base_classes/NXinstrument_apm.nxdl.xml @@ -121,13 +121,13 @@ or volatile (meta)data.--> - + A counter electrode of the LEAP 6000 series atom probes. - + A local electrode guiding the ion flight path. Also called counter or extraction electrode. @@ -142,8 +142,8 @@ or volatile (meta)data.--> The type of aperture used when the local_electrode has an aperture or acts as an aperture in addition to acting as an extraction electrode. - The local electrode is a component which combines functionalities of :ref:`NXlens_em`, - :ref:`NXaperture`, if not even :ref:`NXdeflector`: + The local electrode is a component which combines functionalities + of :ref:`NXelectromagnetic_lens`, :ref:`NXaperture`, if not even :ref:`NXdeflector`: * "n/a", use when no aperture is present in the experiment * "conical", conical aperture with a circular hole diff --git a/base_classes/NXinstrument_em.nxdl.xml b/base_classes/NXinstrument_em.nxdl.xml index e545663f38..3e4b358e18 100644 --- a/base_classes/NXinstrument_em.nxdl.xml +++ b/base_classes/NXinstrument_em.nxdl.xml @@ -77,7 +77,7 @@ - + Description of the type of the detector. diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml index 1fe7e814ce..e23b87ca65 100644 --- a/base_classes/NXpeak.nxdl.xml +++ b/base_classes/NXpeak.nxdl.xml @@ -28,14 +28,14 @@ - Rank of the dependent and independent data arrays (for - multivariate scalar-valued fit.) + Rank of the dependent and independent data arrays + (for multivariate scalar-valued fit). Base class for describing a peak, its functional form, and support values - (i.e., the discretization (points) at which the function has been evaluated). + i.e., the discretization points at which the function has been evaluated. @@ -51,7 +51,7 @@ - The ``position`` field must have the same rank (``dimRank``) + The ``position`` field must have the same rank ``dimRank`` as the ``intensity`` field. Each individual dimension of ``position`` must have the same number of points as the corresponding dimension in the ``intensity`` field. @@ -64,7 +64,7 @@ - The ``intensity`` field must have the same rank (``dimRank``) + The ``intensity`` field must have the same rank ``dimRank`` as the ``intensity`` field. Each individual dimension of ``position`` must have the same number of points as the corresponding dimension in the ``position`` field. @@ -74,8 +74,8 @@ - The functional form of the peak. This could be a Gaussian, Lorentzian, - Voigt, etc. + The functional form of the peak. This could be a Gaussian, Lorentzian, Voigt, + etc. diff --git a/base_classes/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml index 9a9f301e0d..bc906b23b9 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/base_classes/NXprogram.nxdl.xml @@ -22,30 +22,25 @@ # For further information, see http://www.nexusformat.org --> - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - Base class to describe a software tool or library. + Base class to describe a software tool or library. - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Given name of the program. Program can be a commercial one a script, + or a library or a library component. - Program version plus build number, or commit hash. + 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. + 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/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscan_controller.nxdl.xml similarity index 94% rename from base_classes/NXscanbox_em.nxdl.xml rename to base_classes/NXscan_controller.nxdl.xml index 0fc0dce988..b839a851b0 100644 --- a/base_classes/NXscanbox_em.nxdl.xml +++ b/base_classes/NXscan_controller.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The scan box or scan controller is a component that is used to deflect a beam of charged particles in a controlled manner. @@ -29,7 +29,7 @@ The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, which is not necessarily the same program as the one controlling other parts of the instrument. - The scanbox directs the probe of charged particles (electrons, ions) + The scan box directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. diff --git a/base_classes/NXspindispersion.nxdl.xml b/base_classes/NXspindispersion.nxdl.xml index f1ac6bcc6a..1de107b3cd 100644 --- a/base_classes/NXspindispersion.nxdl.xml +++ b/base_classes/NXspindispersion.nxdl.xml @@ -72,7 +72,7 @@ Deflectors in the spin dispersive section - + Individual lenses in the spin dispersive section diff --git a/base_classes/nyaml/NXatom.yaml b/base_classes/nyaml/NXatom.yaml index 97f759fe1c..712d05e432 100644 --- a/base_classes/nyaml/NXatom.yaml +++ b/base_classes/nyaml/NXatom.yaml @@ -88,10 +88,12 @@ NXatom(NXobject): dimensions: rank: 2 dim: (n_pos, d) - \@reference_frame(NX_CHAR): + \@depends_on(NX_CHAR): doc: | - Path to a reference frame in which positions are defined - to resolve ambiguity when the reference frame is different + Path to an instance of :ref:`NXcoordinate_system` to document + the reference frame in which the positions are defined. + + This resolves ambiguity when the reference frame is different to the NeXus default reference frame (McStas). occupancy(NX_NUMBER): unit: NX_DIMENSIONLESS @@ -115,11 +117,14 @@ NXatom(NXobject): The constant :math:`c` is either set to number of neutrons :math:`N` or to the special value 255. The special value 255 is used to refer to all isotopes of an element from the IUPAC periodic table. - Exemplified for hydrogen (meaning irrespective which isotope), its hash value is :math:`H = 1 + 255 \cdot 256 = 65281`. - Exemplified for the :math:`^{1}H` hydrogen isotope (:math:`Z = 1, N = 0`), its hash value is :math:`H = 1 + 0 \cdot 256 = 1`. - Exemplified for the :math:`^{2}H` deuterium isotope (:math:`Z = 1, N = 1`), its hash value is :math:`H = 1 + 1 \cdot 256 = 257`. - Exemplified for the :math:`^{3}H` tritium isotope (:math:`Z = 1, N = 2`), its hash value is :math:`H = 1 + 2 \cdot 256 = 513`. - Exemplified for the :math:`^{99}Tc` technetium isotope (:math:`Z = 43, N = 56`), its hash value is :math:`H = 43 + 56 \cdot 256 = 14379`. + Some examples: + + * The element hydrogen (meaning irrespective which isotope), its hash value is :math:`H = 1 + 255 \cdot 256 = 65281`. + * The :math:`^{1}H` hydrogen isotope (:math:`Z = 1, N = 0`), its hash value is :math:`H = 1 + 0 \cdot 256 = 1`. + * The :math:`^{2}H` deuterium isotope (:math:`Z = 1, N = 1`), its hash value is :math:`H = 1 + 1 \cdot 256 = 257`. + * The :math:`^{3}H` tritium isotope (:math:`Z = 1, N = 2`), its hash value is :math:`H = 1 + 2 \cdot 256 = 513`. + * The :math:`^{99}Tc` technetium isotope (:math:`Z = 43, N = 56`), its hash value is :math:`H = 43 + 56 \cdot 256 = 14379`. + The special hash value :math:`0` is a placeholder. This hashing rule implements a bitshift operation. The benefit is that this enables encoding of all @@ -158,7 +163,7 @@ NXatom(NXobject): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e57066e1ede555906f8123210b0f0c42ec8669a0a94d7675d01b902a5b67c321 +# 4206980cd0848593553abf0f86e1635d60421cdb4907604abdf41526bbe3632a # # # # # # A collection with one or more computing nodes each with own resources. @@ -261,6 +249,4 @@ NXcs_profiling(NXobject): # ID is an increasing unsigned integer starting at 1. # # -# # diff --git a/base_classes/nyaml/NXebeam_column.yaml b/base_classes/nyaml/NXebeam_column.yaml index 63ea8ef6ce..10e2470632 100644 --- a/base_classes/nyaml/NXebeam_column.yaml +++ b/base_classes/nyaml/NXebeam_column.yaml @@ -96,7 +96,7 @@ NXebeam_column(NXcomponent): unit: NX_TIME doc: | How long has the source been in operation. - (NXlens_em): + (NXelectromagnetic_lens): (NXaperture): (NXdeflector): blankerID(NXdeflector): @@ -185,10 +185,10 @@ NXebeam_column(NXcomponent): term: Electron Beam url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 (NXcomponent): - scan_controller(NXscanbox_em): + scan_controller(NXscan_controller): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 16ca452eaaf4a1b316ead9f3f2727cc5bff583eb09d1d6267aa54134782cb266 +# cbaec8a59a4f6890e012a26be203da955643a842a209386b1e198542eee4b64f # # # -# -# -# +# # # Base class for an electro-magnetic lens or a compound lens. # # For :ref:`NXtransformations` the origin of the coordinate system is placed -# in the center of the lens (its polepiece, pinhole, or another -# point of reference). The origin should be specified in the :ref:`NXtransformations`. +# in the center of the lens its polepiece, pinhole, or another point of reference. +# The origin should be specified in the :ref:`NXtransformations`. # # For details of electro-magnetic lenses in the literature see e.g. # diff --git a/base_classes/nyaml/NXelectronanalyzer.yaml b/base_classes/nyaml/NXelectronanalyzer.yaml index 1900f3c7ab..cbdf791174 100644 --- a/base_classes/nyaml/NXelectronanalyzer.yaml +++ b/base_classes/nyaml/NXelectronanalyzer.yaml @@ -201,7 +201,7 @@ NXelectronanalyzer(NXcomponent): (NXdeflector): doc: | Deflectors outside the main optics ensembles described by the subclasses - (NXlens_em): + (NXelectromagnetic_lens): doc: | Individual lenses outside the main optics ensembles described by the subclasses (NXfabrication): @@ -210,7 +210,7 @@ NXelectronanalyzer(NXcomponent): Any other resolution not explicitly named in this base class. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 967c4216aca6f2de37207ac0165fb3688087b402c00d8c72ab6a763a145fb53f +# 19c74dca6181b11be20cda210181fbcb56f50081bbf46e9454cce8ff2ccb28ac # # # -# +# # # Base class to describe the volume of interaction for particle-matter interaction. # diff --git a/base_classes/nyaml/NXoptical_system_em.yaml b/base_classes/nyaml/NXem_optical_system.yaml similarity index 96% rename from base_classes/nyaml/NXoptical_system_em.yaml rename to base_classes/nyaml/NXem_optical_system.yaml index e5c6016bcb..6ae78a0f85 100644 --- a/base_classes/nyaml/NXoptical_system_em.yaml +++ b/base_classes/nyaml/NXem_optical_system.yaml @@ -2,7 +2,7 @@ category: base doc: | Base class for qualifying an electron optical system. type: group -NXoptical_system_em(NXobject): +NXem_optical_system(NXobject): camera_length(NX_NUMBER): unit: NX_LENGTH doc: @@ -90,7 +90,7 @@ NXoptical_system_em(NXobject): rotation(NX_NUMBER): unit: NX_ANGLE doc: | - In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated + In the process of passing through an :ref:`NXelectromagnetic_lens` electrons are typically accelerated on a helical path about the optical axis. This causes an image rotation whose strength is affected by the magnification. @@ -139,7 +139,7 @@ NXoptical_system_em(NXobject): url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3c4d0f8e7769e89e527b6ecf6119664bf46a23a0af0b503fe90fb1659a211ce6 +# fef9bdec79829f836cd6aabb31794918ca4edbd347af278401b81beda14f9f1a # # # -# +# # # Base class for qualifying an electron optical system. # @@ -255,7 +255,7 @@ NXoptical_system_em(NXobject): # # # -# In the process of passing through an :ref:`NXlens_em` electrons are typically accelerated +# In the process of passing through an :ref:`NXelectromagnetic_lens` electrons are typically accelerated # on a helical path about the optical axis. This causes an image rotation whose strength # is affected by the magnification. # diff --git a/base_classes/nyaml/NXenergydispersion.yaml b/base_classes/nyaml/NXenergydispersion.yaml index 94f6d96ef9..880ed56044 100644 --- a/base_classes/nyaml/NXenergydispersion.yaml +++ b/base_classes/nyaml/NXenergydispersion.yaml @@ -126,13 +126,13 @@ NXenergydispersion(NXcomponent): (NXdeflector): doc: | Deflectors in the energy dispersive section - (NXlens_em): + (NXelectromagnetic_lens): doc: | Individual lenses in the energy dispersive section (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e2f13c1f4aa880371c13322f9461fe624e2c7a325bf12149166edd8f72b5a644 +# 0217b29a2b3843f36c81b4410357b0a531b5f5bdb14fe7e625dacdd00818c381 # # # # diff --git a/base_classes/nyaml/NXimage.yaml b/base_classes/nyaml/NXimage.yaml index 90c9028c7a..c4261bf3d2 100644 --- a/base_classes/nyaml/NXimage.yaml +++ b/base_classes/nyaml/NXimage.yaml @@ -10,9 +10,10 @@ doc: | pixel and voxel identify the smallest discretization unit. In this case, pixel and voxel are polygonal or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually more appropriate when working with such tilings. + image point is eventually more appropriate when working with such tilings. - Therefore, all docstrings in this base class refer to points (including pixel and voxel i.e. regular tilings). + Therefore, all docstrings in this base class refer to points. Points are considered + exact synonyms for pixel and voxel, which are terms used for regular tilings. Point coordinates identify the location of the barycenter. @@ -41,7 +42,7 @@ doc: | Classically, images depict objects in real space. Such usage of NXimage essentially is equivalent to storing pictures. For this purpose the image_1d, image_2d, or image_3d NXdata instances respectively - should be used with all their axes axis_i, axis_j, axis_k constrained to NeXus Unit Category NX_LENGTH. + should be used such that all their axes axis_i, axis_j, axis_k are constrained to NeXus Unit Category NX_LENGTH. Imaging modes in electron microscopy are typically more versatile, specifically for use cases in scanning transmission electron microscopy, so-called 4DSTEM. In this case, one two-dimensional @@ -57,7 +58,7 @@ symbols: n_m: | Number of image points along the slowest dimension. n_k: | - Number of image points along the slow dimension. + Number of image points along the slow dimension (k equivalent to z). n_j: | Number of image points along the fast dimension (j equivalent to y). n_i: | @@ -622,7 +623,7 @@ NXimage(NXobject): Point coordinate along the fastest dimension. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 43dd29e12e292bdbdc94021d51a153557efdcf3a308f9f900e3cbebcf4d5766e +# fd7ab599805f06505a3619c02e19eb084d3cbc9bf519f2fb9c6fc4bf4b3f2ebb # # # -# +# # # A local electrode guiding the ion flight path. # Also called counter or extraction electrode. @@ -420,8 +420,8 @@ NXinstrument_apm(NXinstrument): # The type of aperture used when the local_electrode has an aperture or acts as an aperture # in addition to acting as an extraction electrode. # -# The local electrode is a component which combines functionalities of :ref:`NXlens_em`, -# :ref:`NXaperture`, if not even :ref:`NXdeflector`: +# The local electrode is a component which combines functionalities +# of :ref:`NXelectromagnetic_lens`, :ref:`NXaperture`, if not even :ref:`NXdeflector`: # # * "n/a", use when no aperture is present in the experiment # * "conical", conical aperture with a circular hole diff --git a/base_classes/nyaml/NXinstrument_em.yaml b/base_classes/nyaml/NXinstrument_em.yaml index dbc0c376b6..823df9f1dc 100644 --- a/base_classes/nyaml/NXinstrument_em.yaml +++ b/base_classes/nyaml/NXinstrument_em.yaml @@ -47,7 +47,7 @@ NXinstrument_em(NXinstrument): (NXibeam_column): # (NXpbeam_column) for adding laser pulsing capabilities (NXsource + x) - (NXoptical_system_em): + (NXem_optical_system): (NXdetector): doc: | Description of the type of the detector. @@ -183,7 +183,7 @@ NXinstrument_em(NXinstrument): (NXactuator): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7b6147010ffb3dfb1a9fa99c941eecc8602c11cbd0bcb2c1887678436af0a5a1 +# 4b56a758c2ec8bb62faf19ecb426b97d7b99d1d87f6fa9df5741c32e857b3cf9 # # # -# +# # # # Description of the type of the detector. diff --git a/base_classes/nyaml/NXpeak.yaml b/base_classes/nyaml/NXpeak.yaml index 8d012dc4e1..1c0a23a98b 100644 --- a/base_classes/nyaml/NXpeak.yaml +++ b/base_classes/nyaml/NXpeak.yaml @@ -1,13 +1,13 @@ category: base doc: | Base class for describing a peak, its functional form, and support values - (i.e., the discretization (points) at which the function has been evaluated). + i.e., the discretization points at which the function has been evaluated. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. dimRank: | - Rank of the dependent and independent data arrays (for - multivariate scalar-valued fit.) + Rank of the dependent and independent data arrays + (for multivariate scalar-valued fit). type: group NXpeak(NXobject): label(NX_CHAR): @@ -23,7 +23,7 @@ NXpeak(NXobject): dimensions: rank: dimRank doc: | - The ``position`` field must have the same rank (``dimRank``) + The ``position`` field must have the same rank ``dimRank`` as the ``intensity`` field. Each individual dimension of ``position`` must have the same number of points as the corresponding dimension in the ``intensity`` field. @@ -34,21 +34,21 @@ NXpeak(NXobject): dimensions: rank: dimRank doc: | - The ``intensity`` field must have the same rank (``dimRank``) + The ``intensity`` field must have the same rank ``dimRank`` as the ``intensity`` field. Each individual dimension of ``position`` must have the same number of points as the corresponding dimension in the ``position`` field. function(NXfit_function): doc: | - The functional form of the peak. This could be a Gaussian, Lorentzian, - Voigt, etc. + The functional form of the peak. This could be a Gaussian, Lorentzian, Voigt, + etc. total_area(NX_NUMBER): unit: NX_ANY doc: | Total area under the curve. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c1ef8c595d09a93e7ad66155a94c084d37deeebf8267fa50809bdefe8f041dbe +# d031e893b82d7cea452fefe22659749f2800907294468a589e45c74bf75d8519 # # # # -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# # -# Base class to describe a software tool or library. +# Base class to describe a software tool or library. # # # -# Given name of the program. Program can be a commercial one a script, -# or a library or a library component. +# Given name of the program. Program can be a commercial one a script, +# or a library or a library component. # # # -# Program version plus build number, or commit hash. +# 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. +# 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/base_classes/nyaml/NXscanbox_em.yaml b/base_classes/nyaml/NXscan_controller.yaml similarity index 94% rename from base_classes/nyaml/NXscanbox_em.yaml rename to base_classes/nyaml/NXscan_controller.yaml index 22bf6bdb2b..c80180add4 100644 --- a/base_classes/nyaml/NXscanbox_em.yaml +++ b/base_classes/nyaml/NXscan_controller.yaml @@ -6,10 +6,10 @@ doc: | The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, which is not necessarily the same program as the one controlling other parts of the instrument. - The scanbox directs the probe of charged particles (electrons, ions) + The scan box directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. type: group -NXscanbox_em(NXcomponent): +NXscan_controller(NXcomponent): # user perspective scan_schema(NX_CHAR): @@ -59,7 +59,7 @@ NXscanbox_em(NXcomponent): (NXcircuit): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8cf16f3012c5e68900c560231e39e80a92b03f9edd08868e79a957c5fd04d5fb +# 255bda2d8a7c0e6ef138a62d20cd276e93691ad987938eb0f44b82e5f8ae9aec # # # -# +# # # The scan box or scan controller is a component that is used to deflect a # beam of charged particles in a controlled manner. @@ -91,7 +91,7 @@ NXscanbox_em(NXcomponent): # The scan box is instructed by (an) instance(s) of :ref:`NXprogram`, some control software, # which is not necessarily the same program as the one controlling other parts of the instrument. # -# The scanbox directs the probe of charged particles (electrons, ions) +# The scan box directs the probe of charged particles (electrons, ions) # to controlled locations according to a scan scheme and plan. # # diff --git a/base_classes/nyaml/NXspindispersion.yaml b/base_classes/nyaml/NXspindispersion.yaml index 0a2263a6f4..a66fd807bb 100644 --- a/base_classes/nyaml/NXspindispersion.yaml +++ b/base_classes/nyaml/NXspindispersion.yaml @@ -36,12 +36,12 @@ NXspindispersion(NXcomponent): (NXdeflector): doc: | Deflectors in the spin dispersive section - (NXlens_em): + (NXelectromagnetic_lens): doc: | Individual lenses in the spin dispersive section # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 30aac623f8f9603313b7688145c7d9063847baf5df564687ec4f064fb6871395 +# a8014ee23c6a0d996b473031efc56cd3ff18aabec189d2b24830055f1104e61b # # # + + + Number of pixel along the slow direction used for the IPF color key. + + + + + Number of pixel along the fast direction used for the IPF color key. + + - Number of pixel along the z slowest direction. + Number of pixel along the slowest direction, typically labeled z or k. - Number of pixel along the y slow direction. + Number of pixel along the slow direction, typically labeled y or j. - Number of pixel along the x fast direction. + Number of pixel along the fast direction, typically labeled x or i. @@ -49,13 +59,8 @@ - Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - - If the field depends_on is not provided but parents of the instance of this base class or its - specializations define an instance of :ref:`NXcoordinate_system`, projection_direction - is defined in this coordinate system. - - If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + Reference to an instance of :ref:`NXcoordinate_system` in which the axes axis_z, + axis_y, and axis_x are defined. @@ -63,24 +68,33 @@ The algorithm whereby orientations are colored. - - + + - The direction along which orientations are projected. + The direction normal vector along which orientations are projected. + + + Reference to an instance of :ref:`NXcoordinate_system` in which the projection_direction is defined. + + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. + + If nothing is provided, it is assumed that projection_direction is defined in the McStas coordinate system. + + - Details about the original grid. - - Here original grid means the grid for which the IPF map was computed when that - IPF map was exported from the tech partner's file format representation. + Details about the original grid, i.e. the grid for which the IPF map was computed + when that IPF map was exported from the tech partner's file format representation. @@ -115,42 +129,38 @@ The main purpose of this map is to offer a normalized default representation of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues - and users of IPF maps together to discuss which pieces of information need storage. - - We are convinced a step-by-step design and community-driven discussion is a practical - strategy to work towards an interoperable description and data model for exchanging - IPF maps as a specific community-accepted method to convey orientation maps. - - 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 one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques an - understanding if the dataset is worth to become reused or repurposed. - - Inverse pole figure color code for each map coordinate. + + Different types of AXISNAME dimensional scale axes are found in practice. A few examples: + + * No scaling, e.g. pixel position values like 0, 1, 2, 3 pixel. + Pixels on the map can be distinguished but that map is disconnected from + any sample surface context and eventually physical scaling + * Scaling but no offset, e.g. calibrated pixel position 0., 0.5, 1.0, 1.5 micron. + Pixels on the map can be compared for their distance to obtain e.g. size of features + but the position of the map relative to the e.g. the sample surface is unclear. + For IPF maps this is the most frequently reported situation. + * Scaling and offset, which resolves also the absolute position of the map in + relation to the sample surface. This is useful information for stitching multiple + mappings together and other processing where precise and accurate + position data are relevant e.g. for correlative materials characterization. + + Three types of dimensional constraints for maps are possible: + + * (n_x, 3), a one-dimensional map, + typically used for coarse sampling and crystal size statistics. + * (n_y, n_x, 3), a two-dimensional map, + the most frequently found reported + * (n_z, n_y, n_x, 3), a three-dimensional map, + these are commonly generated using computational methods, + or in cases multiple EBSD maps have been stitched/reconstructed + into a three-dimensional map. - - - - - + Pixel center coordinate calibrated for step size along the z axis of the map. @@ -159,7 +169,6 @@ tech partners oftentimes do not report to more than calibrated pixel position--> - Pixel center coordinate calibrated for step size along the y axis of the map. @@ -168,7 +177,6 @@ tech partners oftentimes do not report to more than calibrated pixel position--> - Pixel center coordinate calibrated for step size along the x axis of the map. @@ -178,11 +186,9 @@ tech partners oftentimes do not report to more than calibrated pixel position--> - - The color code which maps colors to orientation in the fundamental zone. + The color code which maps color to orientation in the fundamental zone. For each stereographic standard triangle (SST), i.e. a rendering of the fundamental zone of the crystal-symmetry-reduced orientation space @@ -201,24 +207,19 @@ title:--> * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it can not yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. - - - + + + Inverse pole figure color code for each map coordinate. - - + + @@ -227,21 +228,18 @@ title:--> Pixel along the y-axis. - + - Pixel along the x-axis. - + - diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index 3bb1b805dc..c33566afcc 100644 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -3,7 +3,7 @@ - True if MTex renders a scale bar with figures. + True, if MTex renders a scale bar with figures. - True if MTex renders a grid with figures. + True, if MTex renders a grid with figures. diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index c6685eac41..2dbe76ea49 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -3,7 +3,7 @@ - + - Number of pixel per varphi section plot along the :math:`\varphi_1` fastest + Number of pixel per varphi section plot along the :math:`\varphi_2` slow direction. @@ -34,9 +34,9 @@ Number of pixel per varphi section plot along the :math:`\Phi` fast direction. - + - Number of pixel per varphi section plot along the :math:`\varphi_2` slow + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest direction. @@ -64,14 +64,15 @@ - Point group of the crystal structure of the phase for which the here documented phase- - dependent ODF was computed.(following the notation of the International Table of Crystallography). + Point group of the crystal structure of the phase for which the here documented + phase-dependent ODF was computed following the notation of the + International Table of Crystallography. Point group assumed for additionally considered sample symmetries - following the notation of the International Table of Crystallography). + following the notation of the International Table of Crystallography. @@ -121,8 +122,8 @@ - Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most - maxima in decreasing order of the intensity maximum. + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the + kth-most maxima in decreasing order of the intensity maximum. @@ -131,7 +132,7 @@ - Integrated ODF intensity within a theta angular region of the orientation space (SO3) + Integrated ODF intensity within a theta angular region of the orientation space :math:`SO3` about each location (obeying symmetries) as specified for each location. @@ -201,7 +202,6 @@ - Pixel center angular position along the :math:`\Phi` direction. @@ -210,7 +210,6 @@ - Pixel center angular position along the :math:`\varphi_2` direction. @@ -220,5 +219,4 @@ - diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml index 2543e70c62..3c8285419c 100644 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -3,7 +3,7 @@ @@ -64,7 +64,8 @@ - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + Miller (:math:`(hkl)[uvw]`) or Miller-Bravais indices used to specify the pole + figure. @@ -99,7 +100,6 @@ - Pixel center along x direction in the equatorial plane of @@ -110,5 +110,4 @@ - diff --git a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index 442f13f62d..f9387095c3 100644 --- a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -24,20 +24,25 @@ - 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 slip systems. + Number of slip systems. + + + + + Number of indices used for reporting Miller (3) or Miller-Bravais indices (4). - Base class for describing a set of crystallographic slip systems. + Base class for describing a set of crystallographic slip systems. - Bravais lattice type + Bravais lattice type @@ -51,27 +56,27 @@ - Array of Miller indices which describe the crystallographic planes. + Array of Miller indices which describe the crystallographic planes. - - Array of Miller indices which describe the crystallographic direction. + Array of Miller or Miller-Bravais indices that describe the crystallographic + direction. - + - For each slip system a marker whether the specified Miller indices refer to - a specific or a crystallographic equivalent set of the slip system. + For each slip system a marker whether the Miller indices refer to a specific slip system + or to a set of equivalent crystallographic slip systems. diff --git a/contributed_definitions/nyaml/NXmicrostructure_feature.yaml b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml index 30d212e3d9..87b081a63a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_feature.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_feature.yaml @@ -1,11 +1,14 @@ category: base doc: | Base class for documenting structuring features of a microstructure. + + Instances of the class enable sub-grouping of microstructural features + as the abstract base class NXobject should not be used for this purpose. type: group NXmicrostructure_feature(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8afbe5a4c005a47e243ff942505d8700eb461a99cfa0b9b663e52a85ee0b4155 +# 7f908b4200d6261aac14e699145ee87796778c19404f970a2790c7336e2ece66 # # # # # +# +# +# Number of pixel along the slow direction used for the IPF color key. +# +# +# +# +# Number of pixel along the fast direction used for the IPF color key. +# +# # # -# Number of pixel along the z slowest direction. +# Number of pixel along the slowest direction, typically labeled z or k. # # # # -# Number of pixel along the y slow direction. +# Number of pixel along the slow direction, typically labeled y or j. # # # # -# Number of pixel along the x fast direction. +# Number of pixel along the fast direction, typically labeled x or i. # # # @@ -242,13 +238,8 @@ NXmicrostructure_ipf(NXprocess): # # # -# Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. -# -# If the field depends_on is not provided but parents of the instance of this base class or its -# specializations define an instance of :ref:`NXcoordinate_system`, projection_direction -# is defined in this coordinate system. -# -# If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. +# Reference to an instance of :ref:`NXcoordinate_system` in which the axes axis_z, +# axis_y, and axis_x are defined. # # # @@ -256,24 +247,33 @@ NXmicrostructure_ipf(NXprocess): # The algorithm whereby orientations are colored. # # -# -# +# +# # # # # -# The direction along which orientations are projected. +# The direction normal vector along which orientations are projected. # # # # +# +# +# Reference to an instance of :ref:`NXcoordinate_system` in which the projection_direction is defined. +# +# If the field depends_on is not provided but parents of the instance of this base class or its +# specializations define an instance of :ref:`NXcoordinate_system`, projection_direction +# is defined in this coordinate system. +# +# If nothing is provided, it is assumed that projection_direction is defined in the McStas coordinate system. +# +# # # # -# Details about the original grid. -# -# Here original grid means the grid for which the IPF map was computed when that -# IPF map was exported from the tech partner's file format representation. +# Details about the original grid, i.e. the grid for which the IPF map was computed +# when that IPF map was exported from the tech partner's file format representation. # # # @@ -308,42 +308,38 @@ NXmicrostructure_ipf(NXprocess): # # The main purpose of this map is to offer a normalized default representation # of the IPF map for consumption by a research data management system (RDMS). -# This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues -# and users of IPF maps together to discuss which pieces of information need storage. -# -# We are convinced a step-by-step design and community-driven discussion is a practical -# strategy to work towards an interoperable description and data model for exchanging -# IPF maps as a specific community-accepted method to convey orientation maps. -# -# 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 one common understanding which enables also those users who are -# not necessarily experts in all the details of the underlying techniques an -# understanding if the dataset is worth to become reused or repurposed. # -# # -# # # Inverse pole figure color code for each map coordinate. +# +# Different types of AXISNAME dimensional scale axes are found in practice. A few examples: +# +# * No scaling, e.g. pixel position values like 0, 1, 2, 3 pixel. +# Pixels on the map can be distinguished but that map is disconnected from +# any sample surface context and eventually physical scaling +# * Scaling but no offset, e.g. calibrated pixel position 0., 0.5, 1.0, 1.5 micron. +# Pixels on the map can be compared for their distance to obtain e.g. size of features +# but the position of the map relative to the e.g. the sample surface is unclear. +# For IPF maps this is the most frequently reported situation. +# * Scaling and offset, which resolves also the absolute position of the map in +# relation to the sample surface. This is useful information for stitching multiple +# mappings together and other processing where precise and accurate +# position data are relevant e.g. for correlative materials characterization. +# +# Three types of dimensional constraints for maps are possible: +# +# * (n_x, 3), a one-dimensional map, +# typically used for coarse sampling and crystal size statistics. +# * (n_y, n_x, 3), a two-dimensional map, +# the most frequently found reported +# * (n_z, n_y, n_x, 3), a three-dimensional map, +# these are commonly generated using computational methods, +# or in cases multiple EBSD maps have been stitched/reconstructed +# into a three-dimensional map. # -# -# -# -# -# # +# # # # Pixel center coordinate calibrated for step size along the z axis of the map. @@ -352,7 +348,6 @@ NXmicrostructure_ipf(NXprocess): # # # -# # # # Pixel center coordinate calibrated for step size along the y axis of the map. @@ -361,7 +356,6 @@ NXmicrostructure_ipf(NXprocess): # # # -# # # # Pixel center coordinate calibrated for step size along the x axis of the map. @@ -371,11 +365,9 @@ NXmicrostructure_ipf(NXprocess): # # # -# # # -# The color code which maps colors to orientation in the fundamental zone. +# The color code which maps color to orientation in the fundamental zone. # # For each stereographic standard triangle (SST), i.e. a rendering of the # fundamental zone of the crystal-symmetry-reduced orientation space @@ -394,24 +386,19 @@ NXmicrostructure_ipf(NXprocess): # * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). # # Details are implementation-specific and not standardized yet. -# -# Given that the SST has a complicated geometry, it can not yet be -# visualized using tools like H5Web, which is why for now the matrix -# of a rasterized image which is rendered by the backend tool gets -# copied into an RGB matrix to offer a default plot. # -# -# -# +# +# +# # # Inverse pole figure color code for each map coordinate. # # -# -# +# +# # # # @@ -420,21 +407,18 @@ NXmicrostructure_ipf(NXprocess): # Pixel along the y-axis. # # -# +# # # -# # # # Pixel along the x-axis. # # -# +# # # # -# # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index 1247ade433..363a7e4293 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -14,7 +14,7 @@ type: group NXmicrostructure_mtex_config(NXobject): conventions(NXcollection): doc: | - Reference frame and orientation conventions. + MTex reference frame and orientation conventions. Consult the `MTex docs `_ for details. x_axis_direction(NX_CHAR): doc: | @@ -65,10 +65,10 @@ NXmicrostructure_mtex_config(NXobject): TODO with MTex developers show_micron_bar(NX_BOOLEAN): doc: | - True if MTex renders a scale bar with figures. + True, if MTex renders a scale bar with figures. show_coordinates(NX_BOOLEAN): doc: | - True if MTex renders a grid with figures. + True, if MTex renders a grid with figures. pf_anno_fun_hdl: doc: | Code for the function handle used for annotating pole figure plots. @@ -203,13 +203,13 @@ NXmicrostructure_mtex_config(NXobject): # version as an instance of (NXprogram) one for MTex one for Matlab # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 32c667a8f682fa2834350deffda1f237886ccc28172411f4b971cdf8bbfbec50 +# 69087abba8fd927cf17ad7bfd2cc2cd7f5cc4c103a401a1ecd38ca6809b4acf1 # # # # # -# +# # -# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest +# Number of pixel per varphi section plot along the :math:`\varphi_2` slow # direction. # # @@ -192,9 +187,9 @@ NXmicrostructure_odf(NXprocess): # Number of pixel per varphi section plot along the :math:`\Phi` fast direction. # # -# +# # -# Number of pixel per varphi section plot along the :math:`\varphi_2` slow +# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest # direction. # # @@ -222,14 +217,15 @@ NXmicrostructure_odf(NXprocess): # # # -# Point group of the crystal structure of the phase for which the here documented phase- -# dependent ODF was computed.(following the notation of the International Table of Crystallography). +# Point group of the crystal structure of the phase for which the here documented +# phase-dependent ODF was computed following the notation of the +# International Table of Crystallography. # # # # # Point group assumed for additionally considered sample symmetries -# following the notation of the International Table of Crystallography). +# following the notation of the International Table of Crystallography. # # # @@ -279,8 +275,8 @@ NXmicrostructure_odf(NXprocess): # # # -# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most -# maxima in decreasing order of the intensity maximum. +# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the +# kth-most maxima in decreasing order of the intensity maximum. # # # @@ -289,7 +285,7 @@ NXmicrostructure_odf(NXprocess): # # # -# Integrated ODF intensity within a theta angular region of the orientation space (SO3) +# Integrated ODF intensity within a theta angular region of the orientation space :math:`SO3` # about each location (obeying symmetries) as specified for each location. # # @@ -359,7 +355,6 @@ NXmicrostructure_odf(NXprocess): # # # -# # # # Pixel center angular position along the :math:`\Phi` direction. @@ -368,7 +363,6 @@ NXmicrostructure_odf(NXprocess): # # # -# # # # Pixel center angular position along the :math:`\varphi_2` direction. @@ -378,5 +372,4 @@ NXmicrostructure_odf(NXprocess): # # # -# # diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 0315eb0029..06f8d13785 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -16,12 +16,12 @@ NXmicrostructure_pf(NXprocess): Details about the algorithm that was used to compute the pole figure. crystal_symmetry_point_group(NX_CHAR): doc: | - Point group of the crystal structure of the phase for which the pole figure - was computed (according to International Table of Crystallography). + Point group of the crystal structure of the phase for which the pole figure was + computed following the notation of the International Table of Crystallography. specimen_symmetry_point_group(NX_CHAR): doc: | - Point group of assumed sample symmetries (according to International Table of - Crystallography). + Point group of assumed sample symmetries following the + notation of the International Table of Crystallography. # integration windows halfwidth(NX_NUMBER): @@ -30,7 +30,8 @@ NXmicrostructure_pf(NXprocess): Halfwidth of the kernel. miller_indices(NX_CHAR): doc: | - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + Miller (:math:`(hkl)[uvw]`) or Miller-Bravais indices used to specify the pole + figure. resolution(NX_NUMBER): unit: NX_ANGLE doc: | @@ -58,8 +59,6 @@ NXmicrostructure_pf(NXprocess): dimensions: rank: 1 dim: (n_y,) - - # \@long_name(NX_CHAR): axis_x(NX_NUMBER): unit: NX_ANY doc: | @@ -68,17 +67,15 @@ NXmicrostructure_pf(NXprocess): dimensions: rank: 1 dim: (n_x,) - - # \@long_name(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e223447279e34d5e625e75d19036369c8a20ecca8fa14ae7d446aa91917249f5 +# cde4f0f5bbfd471ca65557093c492d7e6d1c90389f5953076647a62cd6241789 # # # @@ -139,7 +136,8 @@ NXmicrostructure_pf(NXprocess): # # # -# Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. +# Miller (:math:`(hkl)[uvw]`) or Miller-Bravais indices used to specify the pole +# figure. # # # @@ -174,7 +172,6 @@ NXmicrostructure_pf(NXprocess): # # # -# # # # Pixel center along x direction in the equatorial plane of @@ -185,5 +182,4 @@ NXmicrostructure_pf(NXprocess): # # # -# # diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml index 9af2f1b534..60c2686f79 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml @@ -6,6 +6,8 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. n: | Number of slip systems. + m: | + Number of indices used for reporting Miller (3) or Miller-Bravais indices (4). type: group NXmicrostructure_slip_system(NXobject): lattice_type(NX_CHAR): @@ -19,26 +21,25 @@ NXmicrostructure_slip_system(NXobject): dimensions: rank: 2 dim: (n, i) - - # fastest changing dimension needs to be i and not 3 because for instance for hexagonal hkil notation is used miller_direction(NX_NUMBER): unit: NX_UNITLESS doc: | - Array of Miller indices which describe the crystallographic direction. + Array of Miller or Miller-Bravais indices that describe the crystallographic + direction. dimensions: rank: 2 - dim: (n, i) + dim: (n, m) is_specific(NX_BOOLEAN): unit: NX_UNITLESS doc: | - For each slip system a marker whether the specified Miller indices refer to - a specific or a crystallographic equivalent set of the slip system. + For each slip system a marker whether the Miller indices refer to a specific slip system + or to a set of equivalent crystallographic slip systems. dimensions: rank: 1 dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d95502300b03898a97e38b85b397fd790484087064691fd448b15f0d0259b66 +# ac1be2e5d31ae8744ee7c60637ccbe064462fe7d6ecce7b0e8ae326b3a25fab3 # # # # # -# Array of Miller indices which describe the crystallographic direction. +# Array of Miller or Miller-Bravais indices that describe the crystallographic +# direction. # # # -# +# # # # # -# For each slip system a marker whether the specified Miller indices refer to -# a specific or a crystallographic equivalent set of the slip system. +# For each slip system a marker whether the Miller indices refer to a specific slip system +# or to a set of equivalent crystallographic slip systems. # # # From eada03fb4a1b466af8cf29a4aeb531428000a7d4 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 21 Jul 2025 18:08:06 +0200 Subject: [PATCH 48/57] Reactivated microstructure, edit NAMED_reference_frameID --- applications/NXapm.nxdl.xml | 2 +- applications/NXem.nxdl.xml | 88 ++++----- applications/nyaml/NXapm.yaml | 6 +- applications/nyaml/NXem.yaml | 180 +++++++++--------- .../nyaml/NXmicrostructure_ipf.yaml | 8 +- 5 files changed, 138 insertions(+), 146 deletions(-) diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml index c2e29fe22a..2a8d3d042b 100644 --- a/applications/NXapm.nxdl.xml +++ b/applications/NXapm.nxdl.xml @@ -673,7 +673,7 @@ - + A coordinate system. Multiple instances require unique names. diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml index 3a207a45f1..2c20ac37d8 100644 --- a/applications/NXem.nxdl.xml +++ b/applications/NXem.nxdl.xml @@ -508,7 +508,7 @@ - + @@ -1703,51 +1703,47 @@ not wish to duplicate all payload data--> - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/applications/nyaml/NXapm.yaml b/applications/nyaml/NXapm.yaml index 4645018df1..cffa923a7c 100644 --- a/applications/nyaml/NXapm.yaml +++ b/applications/nyaml/NXapm.yaml @@ -576,7 +576,7 @@ NXapm(NXobject): between different parametrizations/representations according to convention 6 of reference ``_. enumeration: [p_plus_one, p_minus_one] - NAMED_reference_frame(NXcoordinate_system): + NAMED_reference_frameID(NXcoordinate_system): exists: ['min', '1', 'max', 'unbounded'] nameType: partial doc: | @@ -1531,7 +1531,7 @@ NXapm(NXobject): dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1a42cc4c10e3294b81e4b0d78ab51ccd93d9f6d87ee04eff5a7d7436db9e352e +# 483580e25df51d506e587c0cad18651bb065cab84b3c6fd37d794937cf8344d7 # # # +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index 8a0e1004dd..d469aa0180 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -99,7 +99,7 @@ NXmicrostructure_ipf(NXprocess): these are commonly generated using computational methods, or in cases multiple EBSD maps have been stitched/reconstructed into a three-dimensional map. - + # strictly speaking unit must not be constraint for AXISNAME no scaling axis_z(NX_NUMBER): unit: NX_LENGTH @@ -176,7 +176,7 @@ NXmicrostructure_ipf(NXprocess): # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2fd54fed9b66a852517a7bd63c55551423a58b045b7ece77f1aecfb07b0347bb +# 77a3f07c431a994ce35036efe626a026e4071d506fd0d999d66fcfffdd4ee133 # # # + - + diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml index 3453320467..87d7265f11 100644 --- a/applications/nyaml/NXem.yaml +++ b/applications/nyaml/NXem.yaml @@ -1583,8 +1583,10 @@ NXem(NXobject): nameType: partial exists: ['min', '1', 'max', 'unbounded'] imaging_mode(NX_CHAR): + microstructureID(NXmicrostructure): + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] - # (NXmicrostructure): # exists: optional ebsd(NXem_ebsd): exists: optional @@ -1774,7 +1776,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 90cb9ed051a6f1de2b8def1721272f3cb7cc758ca85c47e10b886af1bf83053a +# 489e61f1a4288df7d9e94635196cb44757b28d61fa805eb1cb5f4bbf4bfe0199 # # # +# # # # diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml index c8959b455d..bbccf17bd8 100644 --- a/base_classes/NXem_ebsd.nxdl.xml +++ b/base_classes/NXem_ebsd.nxdl.xml @@ -610,10 +610,10 @@ Number of scan points in the original mapping. - + + + + An overview of the entire ROI. diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml index 10c580be31..6b807082d8 100644 --- a/base_classes/NXem_img.nxdl.xml +++ b/base_classes/NXem_img.nxdl.xml @@ -53,10 +53,11 @@ + + + A reconstruction of the microstructure or some of its features + based on image information in the parent class. + + - diff --git a/base_classes/nyaml/NXem_ebsd.yaml b/base_classes/nyaml/NXem_ebsd.yaml index 4074e3c9ed..4d72746c75 100644 --- a/base_classes/nyaml/NXem_ebsd.yaml +++ b/base_classes/nyaml/NXem_ebsd.yaml @@ -450,11 +450,10 @@ NXem_ebsd(NXprocess): unit: NX_UNITLESS doc: | Number of scan points in the original mapping. - - # - # - # - # + (NXmicrostructure_odf): + (NXmicrostructure_pf): + (NXmicrostructure_ipf): + (NXmicrostructure): roi(NXdata): doc: | An overview of the entire ROI. @@ -497,7 +496,7 @@ NXem_ebsd(NXprocess): Label for the x axis # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 82a3639815330347d1689d9057a7881b35944b189b49d76b005137bc07062ade +# a61a924ed30260ef20833216c4dd1382f66d9f61651d479f21bdbc4b4236bc12 # # # +# +# +# +# # # # An overview of the entire ROI. diff --git a/base_classes/nyaml/NXem_img.yaml b/base_classes/nyaml/NXem_img.yaml index 06668b77e4..6cfb8bfe97 100644 --- a/base_classes/nyaml/NXem_img.yaml +++ b/base_classes/nyaml/NXem_img.yaml @@ -25,15 +25,13 @@ NXem_img(NXprocess): dimensions: rank: 1 dim: (2,) - - # already implemented connections to representations of microstructures but in this PR not proposed - # (NXmicrostructure): - # doc: | - # A reconstruction of the microstructure or some of its features - # based on image information in the parent class. + (NXmicrostructure): + doc: | + A reconstruction of the microstructure or some of its features + based on image information in the parent class. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 399e311c8610e60a5a7e0d69f1271d29d19e6f12bb1cfe372c34eb72118daf3a +# 4d5fcaf787369734d86cdfb76ee5a9959f41145ad8d345d71835f6d511d1e53b # # # # From 8d6d6e332012984fcf86cbf8bf8e70a89b265733 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 23 Jul 2025 14:51:18 +0200 Subject: [PATCH 50/57] Added NXchemical_composition to NXmicrostructural_feature to allow for per feature composition reporting --- contributed_definitions/NXmicrostructure.nxdl.xml | 6 ------ .../NXmicrostructure_feature.nxdl.xml | 6 ++++++ .../nyaml/NXmicrostructure.yaml | 14 +------------- .../nyaml/NXmicrostructure_feature.yaml | 12 +++++++++++- 4 files changed, 18 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 1177519bcf..50bbb9b368 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -280,12 +280,6 @@ examples for specific frequently discussed microstructural features--> The chemical composition of this microstructure (region). - - - - - - diff --git a/contributed_definitions/NXmicrostructure_feature.nxdl.xml b/contributed_definitions/NXmicrostructure_feature.nxdl.xml index 11a602aa3f..3af8dbeea6 100644 --- a/contributed_definitions/NXmicrostructure_feature.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_feature.nxdl.xml @@ -28,4 +28,10 @@ Instances of the class enable sub-grouping of microstructural features as the abstract base class NXobject should not be used for this purpose. + + + The chemical composition of this microstructural feature or this set of + features. + + diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 96b4f13507..8b35823e07 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -197,12 +197,6 @@ NXmicrostructure(NXobject): chemical_composition(NXchemical_composition): doc: | The chemical composition of this microstructure (region). - normalization(NX_CHAR): - ELEMENT(NXatom): - nameType: any - chemical_symbol(NX_CHAR): - composition(NX_FLOAT): - composition_error(NX_FLOAT): phases(NXmicrostructure_feature): doc: | Different (thermodynamic) phases can be distinguished for the region-of- @@ -678,7 +672,7 @@ NXmicrostructure(NXobject): dim: (n_qj,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8600220a6aaf2b6d382041736e46e1e6ae8825b7f546bece82f34ed3b095efb +# 0043e320305db51c18feb24e529294bd74cf4df5daff3ffae0df536873e16c70 # # # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml index 87d7265f11..2ac8d1c6ca 100644 --- a/applications/nyaml/NXem.yaml +++ b/applications/nyaml/NXem.yaml @@ -1667,49 +1667,51 @@ NXem(NXobject): beta(NX_NUMBER): gamma(NX_NUMBER): space_group(NX_CHAR): + + # phase-specific texture + ipfID(NXmicrostructure_ipf): + nameType: partial + exists: ['min', '1', 'max', 'unbounded'] + color_model(NX_CHAR): + projection_direction(NX_NUMBER): + map(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + data(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + axis_z(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + legend(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_UINT): + nameType: partial + title(NX_CHAR): + exists: recommended + data(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + odfID(NXmicrostructure_odf): + nameType: partial + exists: optional + pfID(NXmicrostructure_pf): + nameType: partial + exists: optional - # foreseen place for phase-specific texture and microstructure representations and statistics - ipfID(NXmicrostructure_ipf): - nameType: partial - exists: ['min', '1', 'max', 'unbounded'] - color_model(NX_CHAR): - projection_direction(NX_NUMBER): - map(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - axis_z(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - legend(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_UINT): - nameType: partial - title(NX_CHAR): - exists: recommended - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - odfID(NXmicrostructure_odf): - nameType: partial - exists: optional - pfID(NXmicrostructure_pf): - nameType: partial - exists: optional + # microstructure of the entire ROI microstructureID(NXmicrostructure): nameType: partial exists: optional @@ -1776,7 +1778,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 489e61f1a4288df7d9e94635196cb44757b28d61fa805eb1cb5f4bbf4bfe0199 +# b57b40656098afdba4a6bacdfe1d41ae0f0a28726c83abae676addd7a93a5ac1 # # # -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # +# +# # -# -# +# # # # diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml index bbccf17bd8..55dcc79d88 100644 --- a/base_classes/NXem_ebsd.nxdl.xml +++ b/base_classes/NXem_ebsd.nxdl.xml @@ -610,9 +610,6 @@ Number of scan points in the original mapping. - - - diff --git a/base_classes/NXphase.nxdl.xml b/base_classes/NXphase.nxdl.xml index 8f6891a3f0..1b2797b910 100644 --- a/base_classes/NXphase.nxdl.xml +++ b/base_classes/NXphase.nxdl.xml @@ -52,9 +52,8 @@ - + + + + diff --git a/base_classes/nyaml/NXem_ebsd.yaml b/base_classes/nyaml/NXem_ebsd.yaml index 4d72746c75..16039bad8f 100644 --- a/base_classes/nyaml/NXem_ebsd.yaml +++ b/base_classes/nyaml/NXem_ebsd.yaml @@ -450,9 +450,6 @@ NXem_ebsd(NXprocess): unit: NX_UNITLESS doc: | Number of scan points in the original mapping. - (NXmicrostructure_odf): - (NXmicrostructure_pf): - (NXmicrostructure_ipf): (NXmicrostructure): roi(NXdata): doc: | @@ -496,7 +493,7 @@ NXem_ebsd(NXprocess): Label for the x axis # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a61a924ed30260ef20833216c4dd1382f66d9f61651d479f21bdbc4b4236bc12 +# e4d80825f51ecf58aa6b84c18e9d949b54e644e91bf3a7f60ddd2250b6a96dae # # # +# +# +# +# # From 2abdca4649edee19a0200859c93612933eaf6809 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 23 Jul 2025 17:07:43 +0200 Subject: [PATCH 52/57] Removing inconsistency of explicit demanding for units in NXem_eds --- applications/NXem.nxdl.xml | 6 +----- applications/nyaml/NXem.yaml | 12 ++---------- 2 files changed, 3 insertions(+), 15 deletions(-) diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml index a38a9b2bbb..bf4973eb39 100644 --- a/applications/NXem.nxdl.xml +++ b/applications/NXem.nxdl.xml @@ -1786,16 +1786,12 @@ not wish to duplicate all payload data--> - - - + - - diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml index 2ac8d1c6ca..3e22fc4ede 100644 --- a/applications/nyaml/NXem.yaml +++ b/applications/nyaml/NXem.yaml @@ -1763,14 +1763,10 @@ NXem(NXobject): title(NX_CHAR): exists: recommended intensity(NX_NUMBER): - \@units(NX_CHAR): - exists: recommended axis_i(NX_NUMBER): \@long_name(NX_CHAR): - \@units(NX_CHAR): axis_j(NX_NUMBER): \@long_name(NX_CHAR): - \@units(NX_CHAR): eels(NXem_eels): exists: optional @@ -1778,7 +1774,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b57b40656098afdba4a6bacdfe1d41ae0f0a28726c83abae676addd7a93a5ac1 +# 2d6293b29884aab61eeef62f813ee0f058d7e87cb7316e8f1796f3f9d93ee569 # # # - + diff --git a/applications/nyaml/NXem.yaml b/applications/nyaml/NXem.yaml index 3e22fc4ede..914509a7e3 100644 --- a/applications/nyaml/NXem.yaml +++ b/applications/nyaml/NXem.yaml @@ -1751,6 +1751,7 @@ NXem(NXobject): \@long_name(NX_CHAR): atom_types(NX_CHAR): ELEMENT_SPECIFIC_MAP(NXimage): + nameType: any exists: ['min', '0', 'max', '118'] iupac_line_candidates(NX_CHAR): exists: recommended @@ -1774,7 +1775,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2d6293b29884aab61eeef62f813ee0f058d7e87cb7316e8f1796f3f9d93ee569 +# 42a56668edd9f76ee1df14d019beb4787653b981334951075cbcfd69c72b3af4 # # # accuracy of reconstruction protocols and their parameterization. Unused values in each row of the matrix are nullified. - Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + Nuclides are identified as hashed nuclide (see :ref:`NXatom`) for further details. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 8d59c6c869..70b945a6e9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -205,7 +205,7 @@ NXapm_paraprobe_nanochem_config(NXobject): accuracy of reconstruction protocols and their parameterization. Unused values in each row of the matrix are nullified. - Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + Nuclides are identified as hashed nuclide (see :ref:`NXatom`) for further details. dimensions: dim: (n_ityp_deloc_cand, n_ivec_max) grid_resolution(NX_FLOAT): @@ -865,7 +865,7 @@ NXapm_paraprobe_nanochem_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 07560fef05d4614ba12d5556e7e60bc1c26975cb78d4fa6a8211d3991130c134 +# 0eadf37c02da9fc5aaff69a50b81be1b98894002216c103a2c3d89ab270fb2ee # # #